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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Project Broadband Radio Access Networks (BRAN). 

The present document defines the functionality required for interworking High PErformance Radio Local Area 
Network Type 2 (HIPERLAN/2) with IEEE 1394 [6]. Separate ETSI documents provide details on the system 
overview, data link control layer, radio link control sublayer, other convergence sublayers and conformance testing 
requirements for HIPERLAN/2. 

The present document is part 3 of a multi-part deliverable covering the Packet based Convergence Layer, as identified 
below: 

Parti: "Common Part"; 

Part 2: "Ethernet Service Specific Convergence Sublayer (SSCS)"; 

Part 3: "IEEE 1394 Service Specific Convergence Sublayer (SSCS)"; 

Part 4: "IEEE 1394 Bridge Specific Functions sub-layer for restricted topology"; 

Part 5: "IEEE 1394 Bridge Specific Functions sub-layer for unrestricted topology". 

Part 1 describes the functionality for adapting variable length packets/frames to the fixed size used in the Data Link 
Control (DLC) layer. Further parts, each defining a Service Specific Convergence Sublayer (SSCS), describe the 
functionality required to support a certain protocol, e.g. IEEE 1394 [6] or Ethernet protocols. The SSCSs all use the 
services of the Common Part and the DLC [2]. It is envisioned that several, independent, service specific parts will be 
defined in the future as market requirements develop. As a result, further parts may be added in the future. 
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1 Scope 

The present document is applicable to HIPERLAN/2 equipment supporting interworking with 1394 buses. 

The present document only addresses the functionality required to transfer IEEE 1394 [6] traffic over the radio interface 
between HIPERLAN/2 devices. It does not address the requirements and technical characteristics for wired network 
interfaces at a HIPERLAN/2 device. 

The present document uses the services provided by the Common Part of the Packet based Convergence Layer and by 
the Data Link Control layers of HIPERLAN/2. 

The present document does not address the requirements and technical characteristics for type approval and 
conformance testing. Those are covered in separate documents. 
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[2] ETSI TS 101 761-2: "Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Data 

Link Control (DEC) Layer; Part 2: Radio Link Control (RLC) sublayer". 

[3] ETSI TS 101 761-1: "Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Data 

Link Control (DEC) Layer; Part 1: Basic Data Transport Functions". 

[4] ETSI TS 101 761-4: "Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Data 

Link Control (DEC) Layer; Part 4: Extension for Home Environment". 

[5] lEC 61883 (1998): "Consumer audio/video equipment - Digital interface". 
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[8] "ETSI Technical Working Procedures" ( http://portal.etsi.org/directives/directives Dec 2000.pdf) . 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

1394 controller: 1394 application that establishes an isochronous connection on a Serial Bus 

1394 SSCS: the contents of the present document 

HL2 1394 bridge layeraccess point: term access point used in the basic specifications replaced by the term central 
controller throughout the present document to reflect that in home environment multiple HL2 devices can act as the 
access point to a fixed network, whereas the whole HL2 network is still controlled by a single entity, the central 
controller 

bridge: pair of two closely coupled serial bus nodes, called portals, capable of connecting two buses in a Serial Bus net 

NOTE: The bridge selectively forwards asynchronous and isochronous packets according to route information 
contained within the portals. 

bus_ID: 10-bit number uniquely specifying a particular bus within a Serial Bus net 

central controller (CC): provides control functionality for the DLC layer equivalent to that of an access point as 
defined by HIPERLAN/2, but is not necessarily attached to a fixed network 

NOTE: The central controller functionality may be embedded in a wireless device. 

extended unique identifier (EUI-64): 64-bit unique number identifiers derived from the lEEE/RAC -provided 

company _id value 

NOTE: These EUI-64 values are, by definition, unique among themselves. 
HL2 1394 bridge layer: refers to the HIPERLAN/2 IEEE 1394 bridge layer 

NOTE: See bibliography. 

HL2 Bus: protocols that provide 1394 asynchronous and isochronous services on a HL2 wireless network 

information element: message used to transfer convergence layer specific information and that is transferred 
transparently by RLC messages 

listener: device that can sink isochronous streams 

mac_ID: each WT is assigned a MAC ID that is unique for the AP by the AP RLC entity during association 

NOTE: The MAC ID is coded with 8 bits. 

mobile terminal: term mobile terminal used in the basic specifications is replaced by the term wireless terminal 
throughout the present document to reflect that in home environment not all HL2 terminals need to be mobile 

node_ID: 16-bit address which distinguishes the node from other nodes in the system 

NOTE: The 10 most significant bits are the same for all nodes on the same bus; this is called the bus_ID. The 6 
least-significant bits are unique for each node on the same bus; this is called the physical_ID. 

octet: eight bits of data 

overlaid connection: lEC 61883 specification defines this operation that allows adding additional listeners to an 
existing connection 

physicalJD: 6-bit number uniquely specifying a particular node on a 1394 bus 

portal: node that connects a bridge to a Serial Bus 

protocol data unit (PDU): data unit exchanged between entities at the same ISO layer 
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quadlet: four bytes, or 32 bits, of data 



reserved codes: set of values for a defined field that are not used within the present document, but are reserved for 
future revisions of the present document 

NOTE: A reserved code shall not be generated or, upon development of a future standard, may be used as 

specified by such a standard. The recipient of a reserved code shall check its value and shall reject code 
values that were not defined at the time of its inception. 

reserved fields: set of bits not defined by the present document, but reserved for future revisions of the present 
document 

NOTE: A reserved field shall be zeroed or, upon development of a future standard, set to a value specified by 
such a standard. The recipient of a reserved field shall not check its value. 

service data unit (SDU): data unit exchanged between adjacent ISO layers 

talker: device that can source isochronous streams 

wired 1394: refers to a wired bus as specified in IEEE Std 1394-1995 as amended by IEEE Std 1394a-2000, and 
supplemented with lEC 61883 

wireless 1394: refers to a HL2 Bus as specified in the present document 

wireless bridge: bridge which a least one of its portals is wireless 

wireless cycle master: refers to the cycle master on the HL2 Bus 

wireless node: device that belongs to the HL2 Bus and that implements the 1394 SSCS without any bridging functions 
on top of it 

NOTE: A wireless node is identical to a wireless terminal. The term wireless node is used when describing HL2 
Bus behaviour. 

wireless portal: wireless node that implements the HL2 1394 bridge layer, in addition of the 1394 SSCS 

wireless terminal (WT): HL2 home device, which is not acting as a central controller for a subnet 

NOTE: A wireless terminal is identical to a wireless node which is not acting as a central controller. The term 
wireless terminal is used when describing WT behaviour compared to CC behaviour. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

05 jg Hexadecimal notation 

0000 1 1 2 Binary notation 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AP Access Point 

BRAN Broadband Radio Access Networks (Project) 

CC Central Controller 

CL Convergence Layer 

CPCS Common Part Convergence Sublayer 

C-SAP Control Service Access Point 

CSR Control and Status Register 

DLC Data Link Control 

DUC DLC User Connection 

EUI-64 Extended Unique Identifier 

HARP HIPERLAN/2 Address Resolution Protocol 
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HIPERLAN/2 High PERfromance Radio Local Area Network Type 2 

HL2 HIPERLAN/2 

ID IDentifier 

IE Information Element 

IEEE Institute of Electrical and Electronics Engineers 

iPCR input Plug Control Register 

IRM Isochronous Resource Manager 

LAN Local Area Network 

LSB Least Significant Bit 

MAC Medium Access Control 

MSB Most Significant Bit 

oPCR output Plug Control Register 

PCR Plug Control Register 

PDU Protocol Data Unit 

RLC Radio Link Control 

SAP Service Access Point 

SDU Service Data Unit 

Self_ID SelflDentify 

SSCS Service Specific Convergence Sublayer 

WCM Wireless Cycle Master 

WCS Wireless Cycle Slave 

WT Wireless Terminal 



Overview 



4.1 



The 1394 SSCS 



The IEEE 1394 Service Specific Convergence Sublayer (SSCS) is a part of the Packet based Convergence Layer and it 
resides on top of the Common Part and the DLC, as shown in figure 1 . The support of the DLC extensions for the home 
environment, as described in [4], is mandated by the 1394 SSCS. 

The aim of this sublayer is to mimic the functions provided by IEEE 1394 [6] link layer. Bridge functions are out of the 
scope of the present document. They are defined in the HIPERLAN/2 1394 bridge layer (see bibliography). The 
HIPERLAN/2 protocol stack defined in the present document replaces the wired 1394 physical and link layer. The 
services and primitives provided by the 1394 SSCS are a subset of those provided by the wired 1394 physical and link 
stacks. Basic wired 1394 services and primitives are provided by the 1394 SSCS. Some of the wired 1394 services and 
primitives are related to the cable environment and the corresponding physical layer. They are not relevant for the 
HIPERLAN/2 environment, and thus not provided by the 1394 SSCS. 

The 1394 SSCS allows the transportation of wired- 1394 asynchronous and isochronous packets over HIPERLAN/2. 
It also provides 1394 clock propagation over HIPERLAN/2. 
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Higher layers 



CL User SAP 



Packet based Convergence Layer 



Part 3: IEEE 1394 Service Specific Convergence Sublayer 



Part 1 : Common Part 



Common Part Convergence Sublayer 



Segmentation and Re-assembly 



DLC User SAP 



HIPERLAN 2 Data Link Control Layer 



HIPERLAN 2 Physical Layer 



Figure 1 : IEEE 1394 [6] packet based convergence layer 

The 1394 SSCS consists of a user plane and a control plane. 

The user plane, described in clause 5, provides services to the higher layer via the CL-Service Access Point (SAP) and 
uses the services of the Common Part of the Packet based Convergence Layer [1]. 

The control plane, described in clause 6, interacts with the DLC control plane, i.e. the RLC sublayer, via the DLC 
Control SAP. It also uses the services of the Common Part of the Packet based Convergence Layer [1]. The DLC 
Control SAP is defined in [2] and [4]. 

The 1394 SSCS may be present in two types of devices: 

• Wireless 1394 bridge devices: these devices contain bridge functions to allow the connection of a HIPERLAN/2 
network to a wired- 1394 bus or to another wireless network. A wireless bridge device has at least one of its 
portals that belong to the HlPERLAN/2 network. The wireless portal shall implement both the 1394 SSCS and 
the HlPERLAN/2 1394 bridge layer. 

• Wireless 1394 devices: these devices implement only the 1394 SSCS, and thus they do not provide any bridge 
functions (see in figure 2). 
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4.2 



Figure 2: Protocol stack of a non-bridge wireless 1394 device 



HIPERLAN/2 Bus 



The net topology when applied to HIPERLAN/2 is shown in figure 3. The HIPERLAN/2 network appears as a 
wired- 1394 bus for all the attached nodes. This bus is called a HIPERLAN/2 Bus, which is often abbreviated as HL2 
Bus. Regarding the HL2 Bus, all wireless nodes are peers (there is no particular base station). Regarding the 
HIPERLAN/2 network there is however one device in the cell which acts as the CC. 




Wireless Bridge 



IEEE1394BUS 
Figure 3: HL2 Bus connecting bridge and non-bridge 1394 devices 
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4.3 Numbering and coding conventions 

Information elements and PDU are transferred between the 1394 SSCS and the underlying protocol layers in units of 
octets, in ascending numerical octet order (i.e. octet 1, 2, ..., n-1, n), see figure 4. 



MSB 



Bits 



LSB 





8|7|6|5|4|3|2|1 


Octet 1 




Octet 2 








Octet N-1 




Octet N 





Figure 4: Format convention 

When a bit is contained within a single octet, the highest bit number (i.e. labelled 8) represents the high order or most 
significant bit (MSB). 

In a multi-octet field, the order (i.e. the significance) of bit values within each octet decreases as the octet number 
increases. For example, a 16-bit field is coded in figure 5. 



MSB 



Bits 



LSB 





8 


7 


6 


5 


4 


3 


2 


1 


Octet 1 


2^5 (MSB) 


214 


213 


212 


211 


2lO 


29 


28 


Octet 2 


27 


26 


25 


24 


23 


22 


21 


2° (LSB) 



Figure 5: Corresponding coding in an IE or PDU 



User plane services 



5.1 



General 



The user plane procedures of the 1394 SSCS provide the capabilities to transfer 1394 SSCS SDUs between two wireless 
1394 devices over the HIPERLAN/2 network. 

The behaviour of the user plane procedures for CC and WT is identical. 

User plane services cover: 

a) Transport of 1394 SSCS SDU for both asynchronous and isochronous data. 

b) Clock synchronization service: this function provides a mechanism that allows any isochronous capable node to 
have its own cycle clock synchronized to the cycle clock of a single node. 



5.2 Primitives (informative) 



The higher layers (node or bridge applications) access to the 1394 SSCS is defined by the service primitives defined in 
this clause. Normative definitions are therefore contained in [7] and HL2 1394 bridge layer (see bibliography), for node 
and bridge applications respectively. 

NOTE: The primitives are defined only for the purpose of describing layer-to-layer and sublayer-to-sublayer 

interactions. These primitives are defined as an abstract list of parameters, and their concrete realization 
may vary between implementations. No formal testing of primitives is intended. The following primitive 
definitions have no normative significance. 
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5.2.1 Primitive types 

Interface between layers 

Four primitive types may be used between different layers: 

request, for a higher layer to request service from a lower layer; 

confirm, for the layer providing the service to confirm the activity has been completed; 

indication, for a layer providing service to notify the next higher layer of any specific service related activity; 

response, for a layer to acknowledge receipt of an indication primitive from the next lower layer. 

Interface between sublayers 

Two different primitives may be used between different sublayers. To indicate the absence of a Service Access Point 
these primitives differ to the primitives between different layers: 

invoke, for a higher layer to request service from a lower layer; 

signal, for a layer providing service to notify the next higher layer of any specific service related activity. 
The defined types for each category of primitive are shown as a list in curly brackets. 

EXAMPLE: CL_UNITDATA {request, indication} 
In this example, the defined types are request and indication but not confirm or response. 

5.2.2 Parameter definitions 

Message unit: each piece of higher layer information that is included in the primitive is called a message unit. A series 
of one or more message units may be associated with each primitive where each separate unit is related to one 
information element in the corresponding DEC layer message. The list of message units is derived from the message 
definitions by reference to the information elements that may contain information from or (to) the CE. 

5.2.3 Interface to tine upper layer 
5.2.3.1 Primitives related to isochronous traffic 

These primitives are used either by a HE2 1394 bridge layer entity (see bibliography) or by a streaming application. 

5.2.3.1.1 CL_ISOCH_STREAM {request, indication} 

This primitive is used to transmit isochronous packets on the bus, using parameters specified in table 1. This primitive is 
not confirmed. 

Table 1 : CL_ISOCH_STREAM parameters 



parameter 


request 


confirm 


indication 


response 


Message units (possible elements) 

time_stamp 

isoch_header 

interface data (SSCS SDU) 


always 
always 
always 


- 


always 
always 
always 


- 



The time_stamp parameter specifies a 32 bits time stamp that shall be inserted in the 1394 SSCS PDU. 

The isochjieader parameter includes tag, channel, tcode, and sy field, as defined by wired 1394. 

The interface _data parameter consists of the data and /?flii bytes, as well as datajCRC fields, as defined by wired 1394. 
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5.2.3.1.2 CL_CYCLE_SYNCH {indication} 

The 1394 SSCS entity uses this primitive to indicate to the upper layer that an isochronous period has passed (i.e. that 
CYCLE_TlME.offset_count has overflowed), using parameters specified in table 2. This primitive is not confirmed. 

Table 2: CL_CYCLE_SYNCH parameters 



parameter 


request 


confirm 


indication 


response 


Message units (possible elements) 
current_seconds_count 
current_cycle_count 


- 


- 


always 
always 


- 



The current _seconds_count parameter contains the current value of the BUS_T1ME register. 
The current _cycle_count parameter contains the current CYCLEJ^lME.cycle_count value. 

5.2.3.2 Primitives related to asynchronous traffic 

These primitives are used by a 1394 Transaction Layer. 

5.2.3.2.1 CL_ASYNC_ACTION {request, indication, confirm, response} 

This primitive is used to transmit one primary asynchronous packet on the HIPERLAN/2 bus, using parameters 
specified in table 3. 

Table 3: CL_ASYNC_ACTION parameters 



parameter 


request 


confirm 


indication 


response 


IVIessage units (possible elements) 










time of life 


always 


- 


always 


- 


response flag 


always 


- 


always 


- 


interface_data (SSCS SDU) 


always 


- 


always 


- 


crc result 


- 


- 


always 


always 


reply 


- 


always 


- 


always 



The time_of_life parameter is used to indicate how long this packet is allowed to live in the HL2 Bus. It may be 
negative, in that case an upper layer receiving it in an indication could take appropriate actions (such as discard the 
packet). 

The response ^ag parameter differentiates between request and response packets, for the purposes of determining 
which DUC shall be used. 

The interface _data parameter consists of an asynchronous subaction (request or response) packet, as defined by 
wired 1394. 

The reply code has one of the following values: 

reply_accepted the interface data was accepted, but has not necessarily been transferred over the HL2 Bus. 

reply_busy the interface data was rejected because buffer space was temporarily unavailable. 

reply_missing the interface data could not be delivered because the destination_ID is invalid. 

The crc_result parameter indicates when the datajCRC was found to be invalid. 
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5.2.3.2.2 CL_ASYNC_STREAM {request, indication} 

This primitive is used to transmit asynchronous stream packets on the bus, using parameters specified in table 4. This 
primitive is not confirmed. 

Table 4: CL_ASYNC_STREAM parameters 



parameter 


request 


confirm 


indication 


response 


Message units (possible elements) 










time of life 


always 


- 


always 


- 


async_header 


always 


- 


always 


- 


interface_data (SSCS SDU) 


always 


- 


always 


- 


crc result 


- 


- 


always 


- 



The time_of_life is used to indicate how long this packet is allowed to live in the HL2 Bus. It may be negative, in that 
case an upper layer receiving it in an indication could take appropriate actions (such as discard the packet). 

The asyncjieader parameter consists of the asynchronous stream packet header as defined by wired 1394. 

The interface _data parameter consists of the header, header_CRC, data, pad, and data_CRC fields, as defined by 
wired 1394. 

The crc_result parameter indicates when the data_CRC was found to be invalid. 

5.2.4 Interface to the common part 

The primitive CPCS_UNITDATA {invoke, signal}, defined in [1], is used by the user plane procedures of the 
1394 SSCS. 



5.3 Clock synchronization service 



5.3.1 General 

Clock synchronization service aims to provide the means to synchronize clock registers of wireless nodes to their 
corresponding registers at the wireless cycle master (WCM) node. Clock registers are the following: 

- BUS_TIME, 

- CYCLE_TIME, 

- LOCAL_SECONDS, 

- LOCAL_CYCLES. 

BUS_TIME and CYCLE_TIME registers are related to isochronous traffic, and shall be implemented by all 
isochronous capable wireless nodes. These registers are synchronized to the BUS_TIME and CYCLE_TIME registers 
of the WCM. 

LOCAL_SECONDS and LOCAL_CYCLES maintain a local time within the HL2 Bus and shall be implemented by all 
wireless nodes. These registers are synchronized to the LOCAL_SECONDS and LOCAL_CYCLES registers of the 
WCM. The characteristic of these two registers is that they have to ensure that the time passes continuously. 
LOCAL_SECONDS and LOCAL_CYCLES registers of the WCM shall not be modified by the network cycle master 
in order to prevent any time discontinuities (see also in clause 6.5.2.2). LOCAL_SECONDS and LOCAL_CYCLES 
registers have only local significance. Time maintained by these registers is used by wireless nodes to timestamp 
asynchronous transactions (see clause 5.4). 

Detailed description of all these registers is given in annex A; clauses A. 1.4, A. 1.5, A. 1.6 and A. 1.7. 

Synchronization principles for BUS_TIME, CYCLE_TIME, LOCAL_SECONDS and LOCAL_CYCLES with their 
corresponding registers at the WCM are similar. The following principle is mainly focused on the synchronization of 
the CYCLE_TIME register. 
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Synchronization principle of the CYCLE_TIME register between the cycle master and a cycle slave is depicted in 
figure 6. Referring to this illustration, when a frame start is observed by the cycle master the CYCLE_TIME register is 
latched in the a register, and when the frame start is observed by a cycle slave the CYCLE_TIME register is latched in 
the b register. The contents of the a register is transmitted to the cycle slave a' register. The time difference between b 
and fl' is used to adjust the CYCLE_TIME register of the cycle slave. 

NOTE: The offset of the clock PDU in the frame is not constant; it may change as depicted in figure 6. 
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Figure 6: Synchronization principle of the CYCLETIIVIE register 

5.3.2 Clock SSCS PDU format 

The WCM shall broadcast clock information into clock PDU, which contains synchronized and local time values, as 
illustrated in figure 7. 
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Figure 7: Clocit SSCS PDU format 

Clock PDU fields are defined as follows: 

The 32-bit isoch_seconds field shall contain the value of the BUS_TIME register at the time when the 
DLC_MAC_FRAME_START primitive was received by the 1394 SSCS entity of the WCM. 

The 13-bit isoch_cycle field shall contain the value of CYCLE_TIME. cycle_count at the time when the 
DLC_MAC_FRAME_START primitive was received by the 1394 SSCS entity of the WCM. 
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The 12-bit isoch_offset field shall contain the value of the CYCLE_TIME. cycle_offset at the time when the 
DLC_MAC_FRAME_START primitive was received by the 1394 SSCS entity of the WCM. 

The 32-bit local_seconds, 13-bit local_cycles and 12-bit local_offset fields are copies of like named fields from 
the LOCAL_SECONDS and LOCAL_CYCLES registers at the time when the DLC_MAC_FRAME_START 
primitive was received by the 1394 SSCS entity of the WCM. 

The A-b\i frame _ counter identifies the number of the MAC frame which preamble was taken as a reference 
point for the initialization of the all other fields of the SSCS PDU. DLC_MAC_FRAME_NUMBER primitive 
furnishes the MAC frame number. 

5.3.3 Procedures 

5.3.3.1 Procedure in the wireless cycle master (WCM) 

Each time the MAC frame start preamble is detected by means of the DLC_MAC_FRAME_START indication 
primitive, the WCM shall take a snap-shot of its BUS_T1ME, CYCLE_T1ME, LOCAL_SECONDS, LOCAL_CYCLES 
registers, and shall construct a SSCS PDU as follows: 

isoch_seconds contains the BUS_TIME.ieconds value, 

isoch_cycles contains the CYCLE_TIME.c3'cZe_coMnf part, 

isoch_ojfset contains the CYCLE_TlME.c>'cZe_oj5^sef part, 

local_seconds contains the LOCAL_SECONDS. seconds register value, 

local_cycles contains the LOCAL_CYCLES.c3'cZe_coMnf part, 

- frame _counter contains the number of the frame which preamble was taken as reference point to all wireless 
nodes. 

The WCM sends this SSCS PDU using the CPCS_UNITDATA invoke primitive to the CPCS entity. 

5.3.3.2 Procedure in a wireless cycle slave (WCS) 

Each time the MAC frame start preamble is detected by means of the DLC_MAC_FRAME_START indication 
primitive, the WCS shall take a snap-shot of its BUS_TIME (if any), CYCLE_TIME (if any), LOCAL_SECONDS, 
LOCAL_CYCLES registers, and shall store the result in a temporary register along with the frame _counter of the 
MAC_FRAME_START primitive. 

When the WCS receives a CPCS_UN1TDATA signal primitive for the clock DLC Connection, it shall check whether 
the received SSCS PDU corresponds to a measured snap-shot (by checking l\\t frame _counter field). If the 
frame_counter matches, the WCS is able to update its clock registers. The way registers are updated is implementation 
dependent. 

In the case the 1394 SSCS entity receives SSCS PDUs from the forwarding channel (see clause 6.5), then snap-shots for 
the two last frames shall be stored in a temporary register. 

5.4 Asynchronous transaction data transport service 
5.4.1 General 

The purpose of the asynchronous transaction service is to reliably communicate asynchronous transaction components, 
i.e. request or response subaction packets, between two 1394 SSCS peer entities. A busy-acknowledge based flow 
control limits the flow rate of the higher level transmitter to that which can be supported by the lower layers. 

The upper layer is responsible for creation and checking of 1394 specified packets, including their headerjCRC and 
datajCRC values. Higher level CRC coverage is a necessity because the undetected error rate of the lower level 
transport (approximately 10"") is less than that expected by 1394. 
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At the higher level, losses of asynchronous packets are detected through timeouts. In support of such timeout protocols, 
higher level transmitters send each packet to the 1394 SSCS entity with a time_of_life parameter, thereby limiting its 
effective lifetime within the HL2 Bus. At the higher level, receivers are required to check the time_of_life parameter, 
discarding these packets if their allocated time-to-live has expired. 

When passing through the 1394 SSCS entity, the packet time_of_life parameter shall be converted to a time_of_death 
label, by adding the current time to the time_of_life parameter. The time_of_death label uses the clock synchronization 
service (at least only the seconds and cycle counts of it). When passed to the higher level, the packet's time_of_death 
parameter shall be returned to a time_of_life parameter, thereby insulating the higher level protocols from the lowest 
level timing parameters. 

5.4.2 Asynchronous SSCS PDU coding 

The 1394 SSCS asynchronous subaction PDU consists of a format, a time-stamp and a wired- 1394 asynchronous 
packet, as illustrated in figure 8. 
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Figure 8: Asynchronous subaction SSCS PDU format 

Each PDU starts with ?i format field that describes which encapsulation scheme is applied for this asynchronous 
subaction packet PDU. Format values are described in table 5. 

Table 5: formaf values 



Value 


Name 


Description 





iso stream bus packet 


Encapsulation of wired-1394 isochronous stream packets 


1 


async stream bus packet 


Encapsulation of wired-1394 asynchronous stream packets 


2 


async subaction 


Encapsulation of asynchronous subaction packets 


3-254 


- 


Reserved 



The 1394 SSCS PDU also contains a time_of_death label. This time_of_death label has 16-bit seconds and 13-bit 
cycles field components, representing time in seconds and multiples of 125 )is units respectively. 

The 2-bit type field specifies the packet type, as specified in table 6. 
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Table 6: Asynchronous subaction fype values 



Value 


Name 


Description 





ASYNC REQUEST 


Asynchronous request and response packet with time of death header 


1 


- 


Reserved 


2 


CLOSE REQUEST 


Clean-closing request (header quadlet only), see clause 6.8.2 


3 


CLOSE RESPONSE 


Clean closing response (header quadlet only), see clause 6.8.2 



The remainder of the packet consists of a subaction as defined by wired 1 394. The tlabel, rt, pri fields, the remaining 
header quadlets, and the data quadlets are processed as user data and (except for their inclusion in the CRC calculations) 
are ignored by the 1394 SSCS entity. Other fields are described in the remainder of this clause and can effect the 1394 
SSCS entity processing. 

The destination _ID that consists of a 10-bit bus_ID and 6-hit physical_ID components specifies which node is intended 
to receive the packet. 

The headerjCRC value is located at a fcoc/e-dependent offset (as defined in [6]) and covers the fourth through 
preceding bytes. The initial four bytes are not covered by the headerjCRC value. 

Some packets contain data after the header_CRC value. For such packets, the datajCRC value covers these data bytes 
and the zero-valued pad bytes defined in [6]. 

5.4.3 Asynchronous packets management 

To transfer asynchronous transaction between two nodes A and B, a single duplex DUC shall be opened, as defined 
in 6.8. One DUC is used to send requests from A to B and responses from B to A, which is sufficient if A is the 
requester and B is the responder. A different DUC (if necessary) would be used to send requests from B to A and 
responses from A to B. This prevents deadlocks that may appear if requests and responses are using a single DLC 
connection. 

Thus, the opening of a DUC necessarily involves the passing of an information element, that specifies whether the 
opening node is the requester or responder. This is further described in clause 6.8.1. 

When a 1394 SSCS receives a CL_COUTROL.asynchronous_path_reset, all open DUCs shall be closed as described 
in clause 6.8.2. 

5.4.4 Procedures 

5.4.4.1 Procedure in the sender 

This service is started on the upper layer request, when using the CL_ASYNC_ACTION request primitive. The service 
involves a sequence of steps, listed below. 

1) If the destination_ID.busID and request/response property (see clause 5.4.3) are associated with an open DUC, 
then skip to step 5. 

2) The destination_ID field is processed to generate physicalAddr, the HL2-bus destination's physical_ID address: 

a) If destinationJD.busJD equals NODE_IDS.feMi_/D (NODE_IDS is a CSR described in annex A), then 
physicalAddr equals destination_ID.physical_ID. 

b) Otherwise, the destination_ID.bus_ID value is used as a parameter of a HARP operation (see clause 6.7) that 
returns a physicalAddr address. If the HARP operation fails to return a valid physicalAddr address, then a 
CL_ASYNC_ACTION confirm, with a reply _missing code, is returned. 

3) The physicalAddr value is processed to retrieve the mac_ID address of the destination node by checking self-ID 
information (see clauses 5.4.3 and 6.4). If no mac_ID address is found, then a CL_ASYNC_ACTION confirm, 
with a reply _missing code, is returned. 

4) If no currently open DUC supports communications with the mac_ID address, then a DUC is opened for this 
purpose as described in clause 6.8. For efficiency, the destination_ID.bus_ID value may remain associated with 
the open DUC until the DUC is closed. 
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5) If the time_of_life value is negative, the packet shall be discarded. Otherwise, the time_of_life is added to the 
time values contained in LOCAL_SECONDS/LOCAL_CYCLES (these are CSRs described in annex A) to 
generate a time_of_death value. The time_of_death value shall then be placed in the seconds/cycles fields of the 
packet. 

6) If buffer space is not available in the lower layer, then a CL_AS YNC_ACTION confirm, with a reply _busy 
code, is returned. Otherwise, the 1394 SSCS PDU is posted to the CPCS in a CPCS_UNITDATA invoke 
primitive and a CL_ASYNC_ACTION confirm, with a reply _accepted code is returned. 

5.4.4.2 Procedure in receiver 

The headerjCRC is checked. If the header is found to be corrupted, the packet is discarded. 

The time values contained in LOCAL_SECONDS/LOCAL_CYCLES (these are CSRs described in annex A) are 
subtracted from the time_of_death value to generate the time_of_life value that is included in the 
CL_AS YNC_ACTION indication primitive. 

The datajCRC is checked and the result of this check is included in the CL_ASYNC_ACTION indication primitive. 

NOTE: For efficiency, a source_ID.bus_ID of a packet received from the requester (see clause 6.8. 1) may be 

associated (as described in clause 5.4.4.1) with the DUC. This has the effect of eliminating the need to do 
an additional HARP when the expected response is returned. 

5.4.5 Broadcast write transaction specificity 

Broadcast write packets (containing OxFFFF in the destination_ID field) shall be mapped in asynchronous SSCS PDUs 
as described in clause 5.4.2 with the exception of the second and cycles fields which shall be ignored in both the 
transmitter and the receiver. The SSCS PDUs shall then be transmitted on the global broadcast channel (as defined in 
table 13). 

5.5 Stream data transport service 

5.5.1 Isoclironous stream data transport service 

5.5.1.1 General 

The purpose of the isochronous stream data transport service is to reliably transmit isochronous streams between two 
1394 SSCS peer entities. 

The upper layer is responsible for the generation and the reception of SDUs, representing individual 125 )is isochronous 
packets. Each SDU is received from the upper layer with a time stamp. This time represents the time when the packet 
was generated. It is encoded in the PDU, as described below, and thus transmitted by the 1394 SSCS entity to its peer so 
that the SDU is delivered to the destination upper layer with the time stamp. The time stamp may then be used by the 
upper layer to provide a constant delay service. 

Each SDU is protected by a 32 bits CRC. Corrupted data are discarded by the 1394 SSCS entity. 

The sending 1394 SSCS entity is responsible for concatenating the product of multiple SDUs into a single larger 2 ms 
PDU. The receiving 1394 SSCS entity is responsible for regenerating multiple SDUs, representing individual 125 )J,s 
isochronous packets from a 2 ms PDU. 
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5.5.1 .2 Isochronous stream SSCS PDU coding 

For efficiency, several SDUs are collected into a single PDU, as illustrated in figure 9 and described in the remainder of 
this part. 
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Figure 9: Isochronous SSCS PDU format 

A SDU is defined here as a 1394 isochronous packet as defined by wired 1394. The associated 1394 isochronous packet 
header is not part of the SDU, but is one of the parameters of the associated primitive (as described in clause 5.2.3. 1 . 1). 

Each PDU starts with ?i format field that describes which encapsulation scheme is applied for this stream PDU. Format 
values are described in table 5. 

A quadlet time-stamp label indicates then the isochronous cycle when the first SDU within the PDU was created. The 
time stamp label has 16-bit seconds and 13-bit cycles field components, representing BUS_T1ME/CYCLE_TIME 
specified time in seconds and cycles (multiples of 125 )is units) respectively. 

The remainder of the packet consists of the concatenation of tagged SDUs. For each SDU, the tag consists of its 
corresponding wired- 1394 header, except that the channel number is replaced by 6-bits of the primitive supplied 
time-stamp value. 
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Figure 10: Isochronous tagged SDU format 

data_length field represents the length of the following tagged SDU. It contains the length of the data field of the 1394 
packet (without comprising the 1394 packet padding bytes). The data_length field is the same as the data_length field 
of the corresponding wired-1394 packet header (retrieved from or sent in the primitive). 

tag field contains the tag field value of the corresponding wired-1394 packet header (retrieved from or sent in the 
primitive). 
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cycle _low field contains the 6 least significant bits of the cycle _count field from the time stamp that came to the 1394 
SSCS entity along with the SDU. 

tcode field contains the tcode field value of the corresponding wired- 1394 packet header (retrieved from or sent in the 
primitive). 

sy field contains the sy field value of the corresponding wired- 1394 packet header (retrieved from or sent in the 
primitive). 

data_quadlets represent data bytes as they were received in the SDU. They may contain padding bytes (the total 
number of data_quadlet bytes represents an integer number of quadlets). 

datajCRC is the data CRC as defined by wired 1394. 

NOTE: data_length field does not necessarily give the SDU size. Some padding bytes may be necessary to add to 
the data_length in order to get the total SDU size. 

5.5.1.3 Procedure 

5.5.1.3.1 Procedure in the sender 

Upon the reception of a CL_ISOCH_STREAM request primitive, the 1394 SSCS entity shall check whether a multicast 
DUC is open for this SDU: the 1394 SSCS entity shall extract the 1394 channel field from the isoch_header primitive 
parameter. It shall then check whether there is an active DLC User Connection for a multicast channel corresponding to 
this 1394 channel (see clause 6.9). If there is no such open DUC, then the SDU shall be discarded. Otherwise, the 1394 
SSCS entity collects several SDUs, received in several CL_ISOCH_STREAM request primitives into a single PDU. 

The 1394 SSCS entity shall encode the seconds and cycles fields of the PDU with the time_stamp value of the first SDU 
(that was received in the CL_ISOCH_STREAM request primitive). 

For each SDU, all the 1394 header fields, except the channel and the header CRC (that were received in the 
CL_ISOCH_STREAM request primitive) are copied into the corresponding fields tagging the SDU {tag, tcode, sy). 

For each SDU, the cycle_low field is encoded with the 6 less significant bits of the time_stamp. c}'cZe_oj5^ief primitive 
parameter. 

datajCRC field is also encoded with the data_CRC from the CL_ISOCH_STREAM request primitive. This 
corresponds to a wired- 1394 data CRC. 

The 1394 SSCS entity shall build and post a PDU to the CPCS every HL2 frame. A DLC primitive 
(DLC_MAC_FRAME_START), described in [4] is available to determine when a HL2 frame starts. 

Each PDU nominally contains 16 SDUs, although the number of SDUs can be less than 16 (if an isochronous packet is 
not sent in every cycle), 15 (if an isochronous packet is sent in every cycle, but the isochronous cycle duration is larger 
than 1/16 of the HL2 frame duration), or 17 (if an isochronous packet is sent in every cycle, but the isochronous cycle 
duration is shorter than 1/16 of the HL2 frame duration). 

SDUs shall not be fragmented among different PDUs. 

If the upper layer does not generate CL_ISOCH_STREAM request primitives within some 2 ms periods, empty PDUs 
may also be generated (a PDU with no SDU). In this case the empty PDU shall contain at least an empty SDU 
(i.e. data_length field encoded with 0, no data_quadlet field and a data_CRC encoded with 0). An empty PDU shall 
have in the seconds and cycles fields as well as in the tag, tcode, sy and cycle _low fields. 

5.5.1 .3.2 Procedure in the receiver 

The 1394 SSCS entity shall regenerate individual SDUs. It shall parse the PDU, and the individual data_length fields to 
recover individual SDUs. Since every data_quadlets field is quadlet aligned (i.e. it corresponds to an integer number of 
quadlets), the data_length field does not necessarily point to the end of the data_quadlets field. 
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For each recovered SDU: 

• The 1394 SSCS entity shall compute the datajCRC field, and discard corrupted SDUs. 

• Based on the cyclejow field of every SDU tag, and on the seconds and cycles fields of the PDU, the 1394 SSCS 
entity shall generate a time_stamp parameter. 

• Based on the SDU tag, the 1394 SSCS entity shall generate the isoch_header primitive parameter corresponding 
to the SDU: tag, tcode and sy are extracted from the received SDU tag and copied as they are in the 
corresponding isoch_header fields. 

The PDU was received on a multicast channel for which there is a correspondence to a 1394 channel, which is 
used to fill the channel field of the isoch_header primitive parameter. 

• The 1394 SSCS entity shall send the SDU along with the time_stamp and isoch_header parameters to the upper 
layer in a CL_lSOCH_STREAM indication primitive. 

The receiver of isochronous streams shall be prepared for these streams to experience a maximum transmission delay of 
8 ms as described in clause C.4.2. 

5.5.2 Asynchronous stream data transport service 

5.5.2.1 General 

The purpose of the asynchronous stream data transport service is to reliably transmit asynchronous streams between two 
1394 SSCS peer entities. 

The upper layer is responsible for the generation and the reception of SDUs, representing individual asynchronous 
stream packets. Each SDU is received from the upper layer with a time_of_life. 

When passing through the 1394 SSCS entity, the packet's time_of_life parameter shall be converted to a time_of_death 
label, by adding the current time to the time_of_life parameter. The time_of_death label uses the clock synchronization 
service (at least only the seconds and cycle counts of it). When passed to the higher level, the packet's time_of_death 
parameter shall be returned to a time_of_life parameter, thereby insulating the higher level protocols from the lowest 
level timing parameters. 

Each SDU is also protected by a 32 bits CRC. Corrupted data are detected by the 1394 SSCS entity, and are signalled to 
the upper layer as corrupted. 

5.5.2.2 Asynchronous stream SSCS PDU coding 

An SDU is defined here as a 1394 asynchronous stream packet as defined by wired 1394. The associated 1394 
asynchronous stream packet header is not part of the SDU, but is one of the parameters of the associated primitive (as 
described in clause 5.2.3.2.2). 
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Figure 1 1 : Asynchronous stream PDU format 

Each PDU starts with ?i format field that describes which encapsulation scheme is applied for this stream PDU. Format 
values are described in table 5. 

A quadlet time_of_death label having a \6-\n\. seconds and 13-bit cycles field components represents time in seconds 
and multiples of 125 )is units respectively. 

data_length field represents the length of the following SDU. It contains the length of the data field of the 1394 packet 
(without comprising the 1394 packet padding bytes). The data_length field is the same as the data_length field of the 
corresponding wired- 1394 packet header (retrieved from or sent in the primitive). 

tag field contains the tag field value of the corresponding wired- 1394 packet header (retrieved from or sent in the 
primitive). 

reserved field corresponds to the channel field of the wired- 1394 packet header, and shall be filled with 0. 

tcode field contains the tcode field value of the corresponding wired- 1394 packet header (retrieved from or sent in the 
primitive). 

sy field contains the sy field value of the corresponding wired- 1394 packet header (retrieved from or sent in the 
primitive). 

data_quadlets represent data bytes as they were received in the SDU. They may contain padding bytes (the total 
number of data_quadlet bytes represents an integer number of quadlets). 

datajCRC is the data CRC as defined by wired 1394. 

5.5.2.3 Procedure 

5.5.2.3.1 Procedure in the sender 

Upon the reception of a CL_ASYNC_STREAM request primitive, the 1394 SSCS entity shall check whether a DLC 
multicast group is existing for this SDU: the 1394 SSCS entity shall extract the 1394 channel field from the 
asyncjieader primitive parameter. It shall then check whether there is a DLC multicast group corresponding to this 
1394 channel (at least whether the 1394 SSCS entity has joined such a DLC multicast group as described in 
clause 6.10). If the 1394 SSCS entity did not join such a DLC multicast group, then the SDU shall be discarded. 
Otherwise, the 1394 SSCS entity shall build a PDU according to clause 5.5.2.2. 

If the time_of_life value is negative, the packet shall be discarded. Otherwise, the time_of_life is added to the time 
values contained in LOCAL_SECONDS/LOCAL_CYCLES (these are CSRs described in annex A) to generate a 
time_of_death value. The time_of_death value shall then be placed in the seconds/cycles fields of the packet. 
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All the 1394 header fields, except the channel and the header CRC (that were received in the CL_ASYNC_STREAM 
request primitive) are copied into the corresponding fields of the PDU {data_length tag, tcode, sy). 

Reserved bits are set to 0. 

If the data_quadlets field is present datajCRC field is also encoded with the data_CRC from the 
CL_ASYNC_STREAM request primitive. This corresponds to a wired-1394 data CRC. If the data_quadlets field is 
absent (as can occur, when a channel is active but no data is available to be transmitted), then the datajCRC value is not 
included on the wired-1394 packet and is therefore not included in the 1394 SSCS PDUs. 

The 1394 SSCS entity shall build and post a PDU to the CPCS in a CPCS_UNITDATA invoke primitive. 

5.5.2.3.2 Procedure in the receiver 

Upon the reception of a CPCS_UNITDATA signal primitive from the CPCS: 



• 



• 



The 1394 SSCS entity shall compute the datajCRC field, if present. The result of this operation is included in 
the CL_ASYNC_STREAM indication primitive. Based on the cyclejow field of every SDU tag, and on the 
seconds and cycles fields of the PDU, the 1394 SSCS entity shall generate a time_stamp parameter. 

The 1394 SSCS entity shall generate the asyncjieader primitive parameter. It shall extract the tag, tcode and sy 
PDU fields and copy as they are in the corresponding async_header fields. 

The PDU was received on a multicast channel for which there is a correspondence to a 1394 channel that is used 
to fill the channel field of the async_header primitive parameter. 

time of life primitive parameter is generated by subtracting the time values contained in 
LOCAL_SECONDS/LOCAL_CYCLES (these are CSRs described in annex A) from the time_of_death value. 

The 1394 SSCS entity shall send the SDU along with the time_of_life and isoch_heade r pcLraxneteis to the upper 
layer in a CL_ASYNC_STREAM indication primitive. 



Control plane services 



6.1 General 

The control plane of the 1394 SSCS interacts with the DLC control plane (i.e. the RLC sublayer) via the DLC Control 
Service Access Point defined in [2]. It also uses the services of the Common Part of the Packet based Convergence 
Layer [1]. 

The following functions are performed by the control plane procedures of the 1394 SSCS: 

a) Triggering of DLC connection setup. This includes: 

• Clock information DLC Connections (done at association time, and when connectivity to the wireless cycle 
master changes); 

• Isochronous and asynchronous streams. This is done on upper layer request using isochronous resource manager 
(IRM) services (as described in clause 6.8); 

• Asynchronous transaction data. This is done when the address resolution mechanism requests it (as described in 
clause 6.5). 

b) Triggering of DLC multicast and broadcast join procedures. This includes: 

• Clock information DLC Connections (done at association time, and when connectivity to the wireless cycle 
master changes); 



• 



Isochronous and asynchronous streams. This is done on upper layer request using plug control register (PCR) 
services (as described in clause 6.8). 
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c) Triggering of a bus reset process. This includes: 

• 1394 physical_ID allocation; 

• Distribution of all the 1394 physicalJDs of the HL2 Bus. 

The following DLC C-SAP primitives defined in [4] are used by the control plane procedures of the 1394 SSCS: 

• DLC_SETUP { request, indication } ; 

• DLC_CONNECT {request, confirm, indication, response}; 

• DLC_RELEASE {request, confirm, indication, response}; 

• DLC_MULTICAST_JOIN {request, confirm, indication, response}; 

• DLC_MULTIC AST_LEAVE { request, indication } ; 

• DLC_MULTIC AST_CONNECT { request, confirm, indication, response } ; 

• DLC_MULTICAST_RELEASE {request, confirm, indication, response}; 

• DLC_MULTIC AST_MODIFY { request, confirm, indication, response } ; 

• DLC_INFO_TRANSFER {request, confirm, indication, response}; 

• DLC_MAC_FRAME_START { indication, response } ; 

• DLC_MAC_FRAME_NUMBER { indication, response } ; 

• DLC_START_CL_HO { indication, response } ; 

• DLC_START_CC { indication, response } . 

The DLC_INFO_TRANSFER primitive corresponds to the RLCJNFO primitive in the RLC layer. The RLCJNFO 
function, which is optional in RLC layer (as described in [2]), shall be mandatory for a RLC that supports the 1394 
SSCS services. 

6.2 Primitives (informative) 

These primitives are used by the upper layer in a wireless 1394 device. 

6.2.1 CL_CONTROL {request, confirm} 

The upper layer uses this service to request the convergence layer to perform specific actions. This service is confirmed. 

Table 7: CL_CONTROL parameters 



parameter 


request 


confirm 


indication 


response 


Message units (possible elements) 










bus reset 


always 


always 


- 


- 


physical_ID_change 


always 


always 


- 


- 


enable_cycle_master 


always 


always 


- 


- 


asynchronousjDath_reset 


always 


always 


- 


- 


nodejype 


always 


always 


- 


- 



The bus_reset parameter is used to initiate a bus reset. 

"[\\t physical _ID _change parameter is used to initiate a bus reset and request a new physical_lD. 

The enable _cycle_master parameter permits to enable/disable wireless cycle master as defined in [6]. 

The asynchronous _path_reset parameter is used to force a reset of the asynchronous data transport service without loss 
of data. This means that all the DUCs being used for the asynchronous data transport service shall be closed. 
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The nodejype parameter indicates the type of the node, as defined in table 8. 

Table 8: node_type values 



Value 


Definition 





Non-bridge device 


1 -3 


Bridge, as defined by HL2 1394 bridge layer 



This information is used in the self identify process as described in clause 6.4. 

6.2.2 CL_SELFJD {indication} 

The bus reset service is further described in clause 6.4. 

It reports to an application layer the self_ID information on the HL2 Bus (number of connected nodes, as well as their 
physical_ID). 

Table 9: CL_SELF_ID parameters 



parameter 


request 


confirm 


indication 


response 


IVIessage units (possible elements) 










current_physical_ID 


- 


- 


always 


- 


node number 


- 


- 


always 


- 


toggle_bit 


- 


- 


always 


- 


For (i=0;i<Node number; i-i-i-) { 










physical_ID 


- 


- 


always 


- 


node type 


- 


- 


always 


- 


IRM flag 
} 


- 


- 


always 


- 



The current jphysical_ID parameter indicates the physical_ID of the current node on the HL2 Bus. 

The node_number field indicates the number of nodes on the HL2 Bus. 

The togglejbit if set to 1 indicates that all non-assigned physicalJDs have been recycled (marked as new) and at least 
one of them reassigned (portals can react accordingly). 

Tht physical _ID parameter indicates the physicalJD of one node on the HL2 Bus. 

The nodejype parameter indicates the type of the node, identified by physicalJD on the HL2 Bus. The coding of this 
parameter is as defined in table 8. 

The IRMJlag parameter indicates if the node identified by the physicalJD on the HL2 Bus is the isochronous resource 
manager. 



6.3 



Association - Initialization 



The CL capabilities (at least the CL version as defined in clause 7.2) should be exchanged between WT and CC 
convergence layers during the HIPERLAN/2 association process. The WT shall complete the association by sending 
one RLC JNFO message containing the EUI_64 information element defined below to the CC. 



Information element 


Reference 


Status 


Total length 
(octets) 


Description 


EUl 64 


7.4.5 


mandatory 


11 


Contains the WT's EUl 64 



The EUI_64 information element shall be transmitted in the «CL-ATTRIBUTE» field of the RLC JNFO and the 
RLC JNFO_ACK messages. 

Once the association procedure (as defined in [2]) is complete), a 1394 SSCS entity that is a wireless cycle master shall 
setup the clock channels (as described in clause 6.5). A 1394 SSCS entity that is a wireless cycle slave shall join the 
multicast clock group as described in clause 6.5). 
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6.4 Bus reset service 

6.4.1 General 

A bus reset can be initiated by any WT in the HL2 Bus, including the CC. The HL2 Bus reset is always controlled by 
the CC. The CC shall initiate a bus reset when: 

a WT associates to the CC; i.e. a wireless node joins the HL2 Bus, 

a WT dissociates from the CC; i.e. a wireless node leaves the HL2 Bus, 

the CC receives a request from a WT to initiate a bus reset, 

the CC receives a request from the upper layer to initiate a bus reset. 

6.4.2 Procedures 

A HL2 Bus reset is not an atomic action and the CC may consume time and resources in order to reliably propagate bus 
reset information. The HL2 Bus reset should be as less disruptive as possible regarding ongoing connections. 

For the CC 1394 SSCS entity a specific state (bus_reset_state) is defined. The CC 1394 SSCS entity enters the 
bus_reset_state as soon as it decides to initiate a bus reset. It leaves the bus_reset_state when the bus reset is completed 
(see clause 6.4.2.3). 

Two types of information element are used by the CC to perform the bus reset: BUS_SUSPEND and BUS_RESUME. 
A third information element, BUS_RESET, is used by WTs to request the CC to initiate a bus reset. 

6.4.2.1 CC or WT initiated bus reset 

A bus reset is CC initiated when an event (such as WT association or WT dissociation) appears in the lower layers. As 
soon as such an event occurs, the CC enters into the bus_reset_state. 

A bus reset may also be WT initiated. A WT requests the CC to initiate a bus reset when it receives a CL_CONTROL 
primitive with either bus_reset or physical_ID_change parameters set. In this case, the WT sends an RLC_INFO 
message containing the BUS_RESET information element defined below to the CC. 



Information element 


Reference 


Status 


Total length 
(octets) 


Description 


BUS RESET 


7.4.9 


mandatory 


5 


Initiates a bus reset 



When the CC receives such an information element, it shall enter in bus_reset_state, and start a bus reset phase. It shall 
also acknowledge the WT by sending an RLC_INFO_ACK message containing the same BUS_RESET information 
element. 

NOTE: When a bus reset is initiated by the upper layer of the device where the CC runs, it can still be considered 
as a WT initiated bus reset, where the BUS_RESET information element flows internally to the device. 

6.4.2.2 Bus reset worst case duration 

The bus reset worst case duration is the maximum time the CC is allowed to spend in bus_reset_state. It starts when the 
CC decides to enter this state, and stops when the BUS_RESUME information element has been received from the last 
WT. This AT time is fixed to 1 second. 

6.4.2.3 Procedure in the CC side 

When entering into the bus_reset_state, the CC shall start the AT timer to monitor the bus reset duration. The CC 1394 
SSCS entity shall then first request an RLC_INFO message containing the BUS_SUSPEND information element 
defined below to be sent to all associated WTs. 
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Information element 


Reference 


Status 


Total length 
(octets) 


Description 


BUS SUSPEND 


7.4.7 


mandatory 


2 


Indicates the start of the bus reset phase 



The BUS_SUSPEND information element shall be transmitted in the «CL-ATTRIBUTE» field of the RLCJNFO 
and RLC_INFO_ACK messages. The CC 1394 SSCS entity shall manage isochronous resources as described in 
clause 6.9.2.4. 

When the CC 1394 SSCS entity has received the notification of the RLC_INFO_ACK message containing the 
BUS_SUSPEND information element from all associated WTs, it shall invoke the CL_SELF_ID indication primitive 
and request an RLC_INFO message containing the BUS_RESUME information element defined below to be sent to all 
associated WTs. 



Information element 


Reference 


Status 


Total length 
(octets) 


Description 


BUS RESUME 


7.4.8 


mandatory 


2xN+3 


Indicates the end of the bus reset phase 



The BUS_RESUME information element shall be transmitted in the «CL-ATTRIBUTE» field of the RLCJNFO 
and RLC_INFO_ACK messages. The BUS_RESUME information element contains the new correlation between 
MAC_ID and physical_ID for all currently associated WTs (see clause 6.4.3 on how physical_IDs are assigned). 

The bus reset is complete when the BUS_RESUME information element has been received from all associated WTs. 
Then the CC leaves the bus_reset_state. 

As said in clause 6.4.2.2, the bus reset duration shall be less than the AT timer. If a bus reset cannot be completed within 
the AT timer, another bus reset shall be started. 

The CC shall take appropriate actions (DFS, WT dissociation, ...) so that it can succeed in one bus reset. The detail of 
these actions is out of the scope of the present document. 

If the CC fails to send the RLC_INFO message containing the BUS_SUSPEND information element to all associated 
WTs, it shall retransmit this message to only those WTs that did not acknowledge it, provided that the AT timer did not 
expire. 

If the CC fails to send the RLC_INFO message containing the BUS_RESUME information element to all associated 
WTs, it shall retransmit this message to only those WTs that did not acknowledge it, provided that the AT timer did not 
expire. 

6.4.2.4 Procedure in the WT side 

When a WT receives an RLC_INFO message containing the BUS_SUSPEND information element, it shall 
acknowledge it by sending an RLC_INFO_ACK message containing the same BUS_SUSPEND information element. 

The behaviour of a WT 1394 SSCS entity after the reception of a BUS_SUSPEND information element shall be as 
follows: 

• all established isochronous connections shall be maintained; 

• for the asynchronous transaction data transport service: 

the 1394 SSCS entity shall reject any CL_ASYNC_ACTION request from its upper layer (i.e. respond with 
an ack_busy to any transaction layer packet) - as a result the upper layer will not be able to initiate new 
resource reservation from this time, 

the 1394 SSCS entity shall process packets coming from the lower layer (the CPCS). This includes internal 
CSR access as well as transaction packets to deliver to the upper layer. The 1394 SSCS entity shall process 
its PCRs, if any, (reset the PCRs, start a timer and wait for a 1394 controller to configure the plus again as 
described in clauses 6.9.2.2 and 6.9.2.3). 

When a WT receives an RLC_INFO message containing the BUS_RESUME information element, it shall acknowledge 
it by sending an RLC_INFO_ACK message containing the same BUS_RESUME information element. 
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The behaviour of a WT 1394 SSCS entity after the reception of a BUS_RESUME information element shall be as 
follows: 

the WT resumes normal processing of asynchronous transactions; 

the WT shall invoke the CL_SELF_1D indication primitive. 

When the upper layer receives a CL_SELF_1D indication primitive, it shall reserve resources that were reserved before 
the bus reset, as defined in clause 6.9, annex C and [5], part 1. 

NOTE: Since a device running a CC 1394 SSCS also contains a WT 1394 SSCS, WT 1394 SSCS behaviour 
when an RLC_lNFO message containing the BUS_RESUME information element is received also 
applies for the device containing the CC. 

If the WT 1394 SSCS receives more than one BUS_SUSPEND information elements before the reception of a 
BUS_RESUME information element, only the first one shall be considered (others shall be ignored). If the WT 1394 
SSCS receives more than one BUS_RESUME information elements with no reception of a BUS_SUSPEND 
information element, only the first one shall be considered (others shall be ignored). 

6.4.3 Assignment of physicalJDs 

As physicalJDs assignment is centrally managed, the CC has to keep as much as possible stable physicalJDs through 
bus resets. The CC shall assign the same physicalJDs to still associated WTs. If the bus reset is WT-initiated, the CC 
shall assign a new physical JD only if the new_phy_ID parameter in the BUS_RESET information element is set to 
one. If a WT leaves (disassociates) and joins (associates) again the HL2 Bus it should be assigned the same 
physicalJD. 

When there is no new physicalJD available and the CC needs to assign a new physicalJD, the CC shall recycle (mark 
as new) all non-assigned physicalJDs and set the toggle bit in the CL_SELFJD primitive and the BUS_RESUME 
information element. When the toggle_bit is set, it indicates that all non-assigned physicalJDs have been recycled and 
at least one of them reassigned. 

6.5 Clock information connection control 
6.5.1 General 

A 1394 channel is reserved and is dedicated to the multicast clock distribution. The 1394 clock channel is defined in 
table 13. Two multicast groups may correspond to this 1394 clock channel (a main and a forwarding group). The main 
group corresponds to clock information directly sent by the WCM. The forwarding group corresponds to clock 
information repeated by the 1394 SSCS entity of the CC. Selection between main and forwarding group is done by 
using the relay bit of the 1394 CHANNEL IE. 

Every HL2 1394 device shall join the main multicast group of the clock channel just after the association phase. The CC 
side of 1394 SSCS entity allocates a multicast macJD for this main multicast group. 

Cycle master function is enabled on a 1394 SSCS entity by invoking the CL_CONTROL request primitive on the 

corresponding entity with enable_cycle_master as primitive parameter. 

A 1394 SSCS entity that contains the IRM function can also enable itself its cycle master function (see clause 6.5.2.1). 

Once the cycle master function is enabled on a device, the 1394 SSCS entity shall setup a multicast DLC connection for 
the clock multicast macJD. According to the DLC multicast procedures (as defined in [4]), every 1394 SSCS entity 
belonging to the clock multicast group (i.e. all the wireless cycle slaves) will get the DLC multicast connection setup. 

If one of the 1394 SSCS entity does not correctly receive the clock information (because no radio contact to the WCM), 
it shall ask to join the forwarding multicast group. 

When at least one WT asks to join the forwarding multicast group, the corresponding multicast DLC connection shall 
be setup. The 1394 SSCS entity of the CC shall also repeat clock information as described in clause 5.3. 
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6.5.2 Wireless cycle master procedure 

6.5.2.1 Wireless cycle master election 

The wireless cycle master (WCM) is the cycle master on the HL2 Bus. 

The 1394 SSCS entity that contains the IRM function (as described in clause 6.9) shall enable its cycle master function 
if no other WCM is operating on the HL2 Bus (no multicast DLC connection is enabled for the multicast group of the 
clock channel). 

If the 1394 SSCS entity receives a CL_CONTROL request primitive with the enable_cycle_master action from its 
upper HL2 1394 bridge layer entity, it shall enable its cycle master function. An upper layer that is not a HL2 1394 
bridge layer entity shall not generate such a request as described in annex C. 

If the 1394 SSCS entity receives a CL_CONTROL request primitive with the disable_cycle_master action from its 
upper HL2 1394 bridge layer entity, it shall disable its cycle master function. An upper layer that is not a HL2 1394 
bridge layer entity shall not generate such a request as described in annex C. 

6.5.2.2 Wireless cycle master operation 

As every device the 1394 SSCS entity shall join the main multicast group of the clock channel during the initialization 
phase. It shall request an RLC_GROUP_JOIN message containing the CHANNEL information element defined below 
to be sent to the CC (if the WCM and the CC functions are hosted by the same device, this message flow is internal). 



Information element 


Reference 


Status 


Total length 
(octets) 


Description 


CHANNEL 


7.4.6 


mandatory 


3 


Contains the channel number 



The CHANNEL information element shall be transmitted in the «CL-ATTRIBUTE» field of the 
RLC_GROUP_JOIN and the RLC_GROUP_JOIN_ACK messages. 

The relay bit, which is defined in clause 6.10.2, is set to 0. 

When the cycle master function is enabled on a device B, the cycle master function may already operate on another 
device A. In that case device B, the new WCM, shall first update its LOCAL_TIME register value based on observed 
values provided by device A, the old WCM, and continues as described below. The LOCAL_TIME register is defined 
in annex A and in clause 5.3. 

When the cycle master function is enabled, the 1394 SSCS entity shall setup the multicast DLC connection for the clock 
multicast mac_ID. It shall use the fixed capacity agreement mode of the DLC (as described in [4]), with one LCH slot 
every frame. It shall use the non acknowledged transport mode of the DLC. 

When the cycle master function is disabled, the 1394 SSCS entity shall release the multicast DLC connection for the 
clock multicast mac_ID. 

When a WCM detects that another WCM is operating on the HL2 Bus, the 1394 SSCS entity that contains the IRM and 
is also WCM shall disable its cycle master function. 



6.5.3 Wireless cycle slave procedure 



The 1394 SSCS entity shall join the main multicast group of the 1394 clock channel during the initialization phase 
(i.e. just after the association phase). It shall request an RLC_GROUP_JOIN message containing the CHANNEL 
information element defined below to be sent to the CC (if the WCM and the CC functions are hosted by the same 
device, this message fiow is internal). 



Information element 


Reference 


Status 


Total length 
(octets) 


Description 


CHANNEL 


7.4.6 


mandatory 


3 


Contains the channel number. 
The re/ay bit, which is defined in 
clause 6.10.2, is set to 0. 



The CHANNEL information element shall be transmitted in the «CL-ATTRIBUTE» field of the 
RLC_GROUP_JOIN and the RLC_GROUP_JOIN_ACK messages. 
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When the multicast DLC connection for the main multicast group of the clock channel is setup, the 1394 SSCS entity 
shall check that the clock information is correctly received. If the clock information is not well received (no or loose 
radio contact with the WCM), the 1394 SSCS entity shall join the forwarding multicast group of the clock channel. It 
shall request an RLC_GROUP_JOIN message containing the CHANNEL information element defined below to be sent 
to the CC (if the WCM and the CC functions are hosted by the same device, this message flow is internal). 



Information element 


Reference 


Status 


Total length 
(octets) 


Description 


CHANNEL 


7.4.6 


mandatory 


3 


Contains the channel number. 
The re/ay bit, which is defined in 
clause 6.9.3.2, is set to 1. 



The CHANNEL information element shall be transmitted in the «CL-ATTRIBUTE» field of the 
RLC_GROUP_JOIN and the RLC_GROUP_JOIN_ACK messages. 

A 1394 SSCS entity shall check it correctly receives the clock information at the initialization, and also during the 
normal operation: the radio contact may change, and the 1394 SSCS entity may have to join the forwarding channel if it 
looses direct contact to the WCM. 

In the same way, a device that joined the forwarding multicast group shall periodically check whether it gets clock 
information from the main channel. If it does, it shall leave the forwarding multicast group by using a 
RLC_GROUP_LEAVE procedure with the CHANNEL information element. 



6.5.4 CC specific procedure 



When a WT joins the forwarding multicast group of the clock channel, the 1394 SSCS entity of the CC shall set up a 
forwarding multicast DLC connection for this group, as defined in clause 6.9.3.2. Parameters for the forwarding DLC 
connection are the same as the main DLC connection (fixed capacity agreement, one LCH slot every frame, 
non-acknowledged transport mode). 

The 1394 SSCS entity of the CC shall release the forwarding multicast DLC connection when it detects that the last WT 
left the forwarding group. 



6.6 CL responsibility handover 



When the 1394 SSCS of the CC receives the DLC_START_CL_HO indication primitive, it means a CC handover is on 
going, and another CC capable device accepted to become the CC (called the new CC hereafter). CC responsibiUty 
handover at the lower layer is described in [4]. 

Then the old CC shall perform the CL responsibility handover as follow: 

It shall perform a bus reset procedure to inform other devices about the ongoing CC handover. 

It shall send a BUS_SUSPEND message to all the devices (WTs and new CC), as described in clause 6.4 with 
the information that the new CC is the IRM. The description of the IRM in the BUS_SUSPEND IE is depicted in 

clause 7.4.7. 

Eventually it sends a BUS_RESUME message to all devices (WTs and CC), as described in clause 6.4. 

The new CC may become the wireless cycle master as defined in clause 6.5. 

Once the bus reset phase is finished, the 1394 SSCS of the old CC indicates the completion of the procedure to 
the DLC layer by a DLC_START_CL_HO response. 

- When the new CC receives a DLC_START_CC indication primitive, it shall respond with a DLC_START_CC 
response primitive. The DLC_START_CC primitive means that the CC handover is completed. 
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NOTE: There is no convergence layer information to be handed over during a CC responsibihty handover. After 
the CC responsibility handover bus reset, isochronous resources will be reclaimed as described in 
clause 6.9. The handle field of the RECLAIM_THIS request contains the mac_ID to be associated with 
the 1394 channel. So that, after the resource reclaim period, the new IRM gets the 

(1394 channel-multicast mac_IDs) pairs that go on. If some resources are not reclaimed after the resource 
reclaim period, it has to be released by the new IRM. The exact interface between the IRM and the RLC 
to retrieve these un-reclaimed resources is out of the scope of the present document. 

6.7 HL2 Address Resolution service (HARP) 
6.7.1 General 

This service is provided as a future-proof feature. This service is attached to the asynchronous transaction data transport 
from the user plane. If the bus_ID part of the destination_ID of the 1394 SSCS SDU is neither set to the HL2 Bus 
bus_ID, neither to 3Fjg (local bus), this service is used in order to resolve the destination address. 

When a 1394 SSCS entity receives SDU of which the destination bus_ID is unknown, it has to initiate the address 
resolution service to get the physical_ID of the destination wireless device. In order to guarantee the accuracy of the 
request, the 1394 SSCS entity uses an acknowledged protocol by polling every node of the HL2 Bus. 

The HARP service uses the DLC_INFO_TRANSFER primitive of the DLC-C-SAP for direct link. 



MTl CL 



MTl RLC 



ARP_REQUEST 



ARP RESPONSE 



MT2 RLC 



RLC INFO 



RLC INFO ACK 



MT2 CL 



ARP_REQUEST 



ARP RESPONSE 



Figure 12: HARP request 

The initiating 1394 SSCS entity sends a HARP_REQUEST to all other WTs, that answers back a HARP_RESPONSE 
indicating whether they are the destination 1394 SSCS entity or not. 
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6.7.2 Procedures 



6.7.2.1 Procedure in the sender 

When a 1394 SSCS entity wants to initiate a HARP, it shall request that an RLC_INFO message containing the 
HARP_REQUEST information element below to be sent to all the wireless nodes. 



Information element 


Reference 


Status 


Total length 
(octets) 


Description 


HARP REQUEST 


7.4.3 


mandatory 


4 


Contains the unknown bus ID 



The HARP_REQUEST information element shall be transmitted in the «CL-ATTR1BUTE» field of the RLC_lNFO 
and the RLC_lNFO_ACK messages. 

When a WT gets an HARP_RESPONSE information element with acceptance of forwarding from another WT, it 
knows whether that WT is the destination wireless device or not. 

HARP protocol shall stop at the first positive response got. If no positive response comes (invalid bus_lD), then the 
1394 SSCS entity generates a response packet (wired-1394 response packet with resp_address_error response code (as 
defined in [6]) to the upper layer. 

6.7.2.2 Procedure in the receiver 

Upon being notified of receiving an RLC_1NF0 message, the 1394 SSCS entity shall request the generation of an 
RLC_lNFO_ACK message containing the HARP_REQUEST information element. Among all the 1394 SSCS entities 
that have received an HARP_REQUEST, only the one that is in charge of forwarding the asynchronous packets to the 
target bus_lD shall set Forwarding bit indication to 1 in the HARP_RESPONSE. It shall also put its own physical_ID in 
the IE. The others shall set this bit to 0. 



Information element 


Reference 


Status 


Total length 
(octets) 


Description 


HARP_RESPONSE 


7.4.4 


Mandatory 


5 


Contains tlie unl<nown busJD and 
physical ID 



The HARP_RESPONSE information element shall be transmitted in the «CL-ATTRIBUTE» field of the 
RLCJNFO and the RLC_1NF0_ACK messages. 

6.8 Asynchronous transaction connection control service 
6.8.1 Asynchronous transaction mapping to a DLC connection 

6.8.1.1 General 

Wired-1394 transactions are mapped on DLC connections as follow: one 1394 SSCS entity uses one DLC duplex 
connection to send transaction requests and receive transaction responses. If the 1394 SSCS entity is intended to receive 
transaction requests from the peer entity, another DLC duplex connection is needed. 

Therefore, when setting up a DLC duplex connection, it is necessary to indicate whether the initiating side is a 
transaction requester or a responder. 

The acknowledged transport mode as defined in [3] shall be used. 

6.8.1.2 Procedures 

The 1394 SSCS initiating the connection shall request the sending of an RLC_DM_SETUP message containing the 
TRANS ACTIONJNDICATOR information element defined below to the other CC. The CC shall forward the IE to the 
peer WT in the subsequent CC_originated RLC_DM_SETUP message. 
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Information element 


Reference 


Status 


Total length 
(octets) 


Description 


TRANSACTIONJNDICATOR 


7.4.10 


mandatory 


3 


Indicates whether the initiating WT 
is the requester or the responder 



The TRANSACTIONJNDICATOR information element shall be transmitted in the «CL-ATTRIBUTE» field of the 
RLC_DM_SETUP message. 

A 1394 SSCS being notified of the reception of an RLC_DM_SETUP message with the 

TRANSACTIONJNDICATOR information element, and accepting the connection shall initiate sending of an 
RLC_DM_CONNECT message with no specific information element. This TRANSACTIONJNDICATOR IE 
indicates whether the WT that initiated the connection is a transaction requester or a responder and respectively. 

6.8.2 Clean closing service 

6.8.2.1 General 

This service is used to clean close DLC user connections. A WT going to close a DLC user connection is thus able to 
purge DLC buffers before closing. This feature allows some devices with limited ARQ resources to cleanly close some 
DLC user connections and swap on others without loosing data. The way a device shares a limited amount of ARQ 
resources between a larger amount of DLC user connections is however out of the scope of the present document. 

6.8.2.2 Clean closing SSCS PDU format 

Clean close request and clean close response PDU are based on an asynchronous subaction SSCS PDU (see 
clause 5.4.2) with the following characteristics: 





8 1 7 1 6 1 5 1 4 


1 3 1 


2 1 1 


Octet 1 


format 


Octet 2 


reserved 


Octet 3 


reserved 


Octet 4 


reserved 


Octet 5 


seconds 


Octet 6 


Octet 7 


cycles 






Octet 8 


reserved 


type 




not used 



Figure 13: clean closing SSCS PDU format 

Format field shall be set to the value 2, which corresponds to the asynchronous subaction, as indicated in table 5. 

Seconds and cycles fields shall be set to 0. 

type field shall be set to either CLOSE_REQUEST or CLOSE_RESPONSE (see in table 6). 

Other asynchronous subaction SSCS PDU fields {destination_ID, tlabel, rt, tcode, pri, header_quadlets, headerjCRC, 
data_quadlets, datajCRC) shall not be included in the remaining part of the PDU. 

6.8.2.3 Procedures 

6.8.2.3.1 Procedure at the initiating side 

When one 1394 SSCS entity wants to close a DLC user connection, it shall send a clean closing request PDU, defined 
in clause 6.8.2.2, to the 1394 SSCS entity of the receiver and start a split timeout, as far a standard 1394 transaction. 

It shall then stop sending user data to this DLC user connection. 

It shall then wait for the reception of a clean closing response SSCS PDU. When either the clean closing response SSCS 
PDU comes back or the split timeout expires, then the 1394 SSCS entity sends a DLC_RELEASE request primitive. 
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6.8.2.3.2 Procedure at the other side 

When a 1394 SSCS entity gets a clean closing request, it has to stop transmitting packets after sending the current one. 

It shall then respond with the clean closing response PDU to the sender. 

The DLC user connection will be released by the clean closing initiator. But as soon as the 1394 SSCS entity sent a 
clean closing response PDU, it shall consider the DUC is not open anymore. 

6.9 Isochronous stream connection control service 
6.9.1 General 

The isochronous stream connection control service is used to allocate resources to the stream data transport service. 

The management of the isochronous resources in a Serial Bus is covered by the isochronous resource manager (IRM) 
function described in wired 1394. It is located in the 1394 SSCS of the CC. The IRM provides channels and bandwidth 
reservation facilities, so that other device applications can make some resource reservation (lock request/lock response). 
The IRM does not provide any BANDWIDTH. AVAILABLE and CHANNEL. AVAILABLE registers. In fact due to 
wireless transmission constraints (link radio quality), there are different physical modes possible when a talker sends 
data to the listener. The selection of the physical mode depends from the radio link quality. Moreover from the selected 
physical mode depends also the duration of the allocated time slots in the MAC frame (this is further detailed in [3] and 
[4]. Therefore, the bandwidth to be reserved (in terms of time duration in the MAC frame) depends from the selected 
physical mode, and thus depends from who is the talker and who is the listener. Therefore a specific command based 
lock request lock response has been defined for the purpose of the IRM resources (see annex A) in order to put the 
bandwidth, the talker, and at least one listener in a single command. The mechanism for isochronous data flow 
management uses the functions described in lEC 61883 [5], clause 7 of part 1, with the exception of the oPCR 
definition, which is described in clause A. 2.1 of the present document. It also uses the connection management 
procedures (CMP), as described in lEC 61883 [5], clause 8 of part 1. 

The 1394 controller reserves bandwidth and channel in the IRM and configures the iPCR and the oPCR. It can also 
modify or release the bandwidth in the IRM. 

An application can connect a device on an IEEE 1394 [6] channel by writing a channel number into its plug control 
register (input plug for devices that receive data from the channel, output plug for devices that send data on the 
channel). 

The oPCR register (or set of registers) shall be implemented in a 1394 SSCS of a device that can source isochronous 
streams. It is defined in clause A.2.1. This device is called a talker. 

The iPCR register (or set of registers) shall be implemented in a 1394 SSCS of a device that can sink isochronous 
streams. It is defined in clause A.2.2. This device is called a listener. 

The oPCR defined here is not totally the same as the one described in the lEC 61883 [5] standard. It is adapted to HL2. 

Isochronous streams shall use fixed capacity agreement, which is a mode of capacity allocation negotiated during DUC 
setup, as defined in [4] . 

Isochronous streams shall use the DLC FEC (forward error correction) transport mode as defined in [4] . 

Relaying of isochronous streams is out of the scope of the present document. Relaying of multicast data is not defined 
in [4]. In the case there is no radio contact between the talker and the listener, or in the case the radio contact gets lost 
between the talker and the listener, the listener will fail in receiving isochronous streams. 

There are some features (link adaptation) in the lower layers (see [3] and [4]) in order to adapt the reception when the 
link radio quality is changed. Therefore, when the link radio quality decreases, another physical mode may be selected. 
If there is sufficient bandwidth, this mechanism is transparent to the 1394 SSCS entity and only requires peer to peer 
DLC protocols. In a similar way, when other listeners join the multicast group, the link adaptation for direct link 
multicast as described in [4] shall be used, so that the correct physical mode is selected. If there is sufficient bandwidth, 
this is also transparent to the 1394 SSCS entity. 

If the link radio quality decreases and there is not enough bandwidth to sustain the connection, then the multicast DLC 
connection is released. When a 1394 SSCS entity observes a DLC multicast connection release, it shall update the 
corresponding PCRs and report to the 1394 controllers that a connection has been released. 
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6.9.2 SSCS procedure 
6.9.2.1 General 

The procedures defined below are used in three types of operations: allocating, reclaiming and releasing resources. 
The wireless devices allocate resources when they want to send or receive streams. 
The action of claiming new resources is split in two scenarios: 

• Non overlaid connection consists in a wireless 1394 channel setup where both the source and the destination are 
connected at the same time. 

• Overlaid connection allows adding listeners to an existing connection. 
The wireless devices shall reclaim resource after a bus reset operation. 

6.9.2.1.1 Resources allocation 

6.9.2.1 .2 Non overlaid connection 

One isochronous channel is mapped to one multicast DUC. 

First, the 1394 controller shall send a command based lock request (as defined in annex A) towards the IRM (containing 
the bandwidth, the talker identifier and one listener identifier) to allocate the channel and the bandwidth. If there are 
available resources, the lock command succeeds. 

The 1394 controller shall then send a lock request to the talker and listener at iPCR and oPCR addresses to set the 
channel of the previous step. 

Both talker and listener shall perform the multicast join procedure on this channel. 

After the multicast join procedure is complete, the CC shall start a multicast setup procedure into the multicast group. 
The stream is opened. 

Then, both the talker and the listener shall send a lock response to the 1394 controller. 
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Figure 14: Non overlaid connection mechanism 

6.9.2.1 .3 Overlaid connection 

A HL2 multicast connection for a channel already exists. 

The 1394 controller shall set the oPCR of the talker to increment the point-to-point connection counter. 

It shall then set the iPCR of the new listener with the channel by sending a lock request. The new listener shall perform 
a multicast join procedure. 

The CC shall start a multicast setup procedure with the new listener. The stream is opened. 

Then, the listener shall send a lock response to the 1394 controller. 
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Figure 15: Overlaid connection mechanism 

6.9.2.1.4 Resources reclaim 

When a 1394 controller is indicated a bus reset, it shall re-allocate all its connections within one second (i.e. send lock 
request to the IRM as described in clause 6.9.2.4, and to the PCRs as described in clause 6.9.2.2 and in clause 6.9.2.3). 
After this time it is not allowed to send either re-allocation or normal allocation messages during the worst case bus 
reset duration time (AT), see in clause 6.4.2.2. But a device can receive and accept a request during this period, as 
defined in clause 6.4. 

The 1394 controller shall wait 1h-AT s to allocate new isochronous resources. 

6.9.2.1 .5 Resources release 

To release the resources allocated to an isochronous channel, the 1394 controller shall release the bandwidth and 
channels reserved in the IRM, by sending the appropriate command to the IRM (see clauses 6.9.2.4 and A.4). 

The talker and the listener can autonomously disconnect from the isochronous stream (if the DLC connection has been 
released) and report that disconnection to the 1394 controller. 

6.9.2.2 Procedure at the talker side 

The talker shall behave as described in lEC 61883 [5] part 1, with some specific HL2 behaviours that are described 
hereafter: 

Resource allocation: 

When the talker receives a lock request from the 1394 controller on its oPCR, and that oPCR's channel field is nonzero, 
it shall process the compare and swap transaction as specified in wired 1394 (compare the arg_value and data_value). 
If the arg_value and data_value are different, then a negative lock response is generated. Otherwise, the talker shall 
initiate a multicast join procedure to the CC on this channel. 



£75/ 



42 



ETSI TS 101 493-3 VI .2.1 (2001-12) 



It shall send an RLC_GROUP_JOIN message containing the CHANNEL information element defined below to the CC. 



Information element 


Reference 


Status 


Total length 
(octets) 


Description 


CHANNEL 


7.4.6 


mandatory 


3 


Contains the channel number 



The CHANNEL information element shall be transmitted in the «CL-ATTRIBUTE» field of the 
RLC_GROUP_JOIN and the RLC_GROUP_JOIN_ACK messages. The relay bit, which is defined in clause 6.9.3.2, is 
set to 0. The talker gets the multicast mac_ID in the RLC_GROUP_JOIN_ACK message. 

When the talker receives an RLC_DM_MC_CONNECT message containing the multicast mac_ID, it shall send a 
positive lock response to the 1394 controller. 

If the multicast join procedure or the multicast setup procedure fails, the talker shall return a lock response with an error 
code in the channel field to the 1394 controller, see clause A. 2. 3. If the multicast setup procedure failed due to transient 
transmission error (timeouts, for instance), a TRANSIENT_ERROR code shall be returned in the lock response and the 
1394 controller is expected to retry the resource allocation. If the error is more severe (such as bandwidth limitations), a 
PERMANENT_ERROR code shall be returned in the lock response and the 1394 controller is not being expected to 
retry the resource allocation. 

Resource reclaim: 

When the talker receives a BUS_SUSPEND information element contained in the «CL-ATTRIBUTE» field of the 
RLC_INFO message, as defined in the bus reset procedure in clause 6.4, it shall reset the oPCR and start a T timer 
(T = 1 s + AT). 

If channel bits are not written before the T timeout, the 1394 SSCS shall generate a multicast leave procedure towards 
the CC to leave the multicast group. 

The talker shall leave the multicast group by sending an RLC_GROUP_LEAVE message to the CC, for the 
corresponding multicast mac_ID. 

Resource release: 

When the point-to-point connection counter field or the broadcast connection counter field of the oPCR is set to by a 
1394 controller, (the talker is disconnected from a channel) then the talker shall release the multicast DLC connection 
corresponding to that channel, by sending an RLC_DM_MC_RELEASE message. It shall leave the multicast group (by 
sending an RLC_GROUP_LEAVE message). 

If the multicast DLC connection is released by the lower layer, then i\\t point-to-point connection counter field and the 
broadcast connection counter field of the oPCR shall be set to 0. The 1394 SSCS entity shall also leave the 
corresponding multicast group (by sending an RLC_GROUP_LEAVE message). It shall also set the disconnected_pcr 
bit in a write request to the INTERRUPT_TARGET CSR of at least the 1394 controllers that modified the 
corresponding oPCR. 

6.9.2.3 Procedure at the listener side 

The listener shall behave as described in lEC 61883 [5], part 1, with some specific HL2 behaviours that are described 
hereafter: 

Resource allocation: 

When the listener receives a lock request from the 1394 controller on its iPCR, and that iPCR's channel field is nonzero, 
it shall process the compare and swap transaction as specified in wired 1394 (compare the arg_value and data_value). 
If the arg_value and data_value are different, then a negative lock response is generated. Otherwise, the listener shall 
initiate a multicast join procedure to the CC on this channel: 

It shall send a RLC_GROUP_JOIN message containing the CHANNEL information element defined below to the CC. 



Information element 


Reference 


status 


Total length 
(octets) 


Description 


CHANNEL 


7.4.6 


mandatory 


3 


Contains the channel number 
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The CHANNEL information element shall be transmitted in the «CL-ATTRIBUTE» field of the 
RLC_GROUP_JOIN and the RLC_GROUP_JOIN_ACK messages. The relay bit, which is defined in clause 6.9.3.2, is 
set to 0. The listener gets the multicast mac_ID in the RLC_GROUP_JOIN_ACK message. 

When the listener receives an RLC_DM_MC_CONNECT message containing the multicast mac_ID, it shall send a 
positive lock response to the 1394 controller. 

If the multicast join procedure or the multicast setup procedure fails, the listener shall return a lock response with an 
error code in the channel field to the 1394 controller, see clause A. 2. 3. If the multicast setup procedure failed due to 
transient transmission error (timeouts, for instance), a TRANSIENT_ERROR code shall be returned in the lock 
response and the 1394 controller is expected to retry the resource allocation. If the error is more severe (such as 
bandwidth limitations), a PERMANENT_ERROR code shall be returned in the lock response and the 1394 controller is 
not being expected to retry the resource allocation. 

Resource reclaim: 

When the listener receives a BUS_SUSPEND information element contained in the «CL-ATTRIBUTE» field of the 
RLC_INFO message, as defined in the bus reset procedure in clause 6.4, it shall reset the iPCR and start a T timer 
(T = 1 s + AT). 

If channel bits are not written before the T timeout, the 1394 SSCS shall generate a multicast leave procedure towards 
the CC to leave the multicast group. 

The listener shall leave the multicast group by sending an RLC_GROUP_LEAVE message to the CC, for the 
corresponding multicast mac_ID. 

Resource release: 

When point-to-point connection counter field or the broadcast connection counter field of the iPCR is set to (the 
listener disconnected from a channel) then the listener shall release the multicast DLC connection corresponding to that 
channel, by sending an RLC_DM_MC_RELEASE message. It shall leave the multicast group (by sending an 
RLC_GROUP_LEAVE message). 

If the multicast DLC connection is released by the lower layer, then the point-to-point connection counter field and the 
broadcast connection counter field of the iPCR shall be set to 0. The 1394 SSCS entity shall also leave the 
corresponding multicast group (by sending an RLC_GROUP_LEAVE message). It shall also set the disconnected_pcr 
bit in a write request to the INTERRUPT_TARGET CSR of at least the 1394 controllers that modified the 
corresponding oPCR. 

6.9.2.4 Procedure at the IRM side 

The IRM can receive different lock request commands, which are defined in clause A.4. 

When the IRM receives a lock request from the 1394 controller, it shall perform the requested action. If the action is 

done, the IRM shall send a lock response to the 1394 controller with the status field set to DONE code. If the action is 

not correctly done, it shall send a lock response to the 1394 controller with the status field set to the appropriate failure 

code. 

The text below describes the different lock request commands. 

Resource allocation on a new channel (ALLOC ATE_SOME): 

If the IRM receives an ALLOCATE_SOME request while being processing a bus reset (i.e. the CC started a bus reset 
and did not complete it yet, see clause 6.4), then an ALLOCATE_SOME response shall be answered (with the status 
field set to RESET code). Neither bandwidth nor channel shall be reserved. 

Else, if the IRM receives an ALLOCATE_SOME request (new resource reservation), containing the talker_ID, the 
listener_ID and the bandwidth parameters, it shall check if it is possible to allocate such bandwidth. The 1394 SSCS of 
the CC gets the information about the link radio quality from the DLC layer. The exact procedure is out of the scope of 
the present document. 

If there are enough available resources, the IRM shall send an ALLOCATE_SOME response with the status field set to 
DONE code and the handle field containing the allocated multicast mac_ID. It shall also update the bandwidth and 
channel in the IRM. 
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If there are not available resources (not enough bandwidth, or all channels already reserved), the IRM shall send an 
ALLOCATE_SOME response, with the status field set to an appropriate failure code (indicating which from the 
bandwidth or the channel was not available). Whatever the failure is (channel or bandwidth failure), neither bandwidth 
nor channel shall be reserved. 

When the IRM receives an RLC_GROUP_JOIN message, it shall perform a multicast join procedure. It shall then 
respond with an RLC_GROUP_JOIN_ACK message. 

When the IRM has completed the multicast join procedure for both the talker and the listener, it shall start a multicast 
setup procedure between the talker and the listener, as described in [4]. The IRM shall send a RLC_DM_MC_SETUP 
message to the WTs in the group. 

If the multicast setup fails, the IRM shall not free resources by itself, but shall wait for the 1394 controller to free 
allocated resources via appropriate lock command. 

Resource allocation on an existing channel (MODIFY_BAND WIDTH) 

If the IRM receives a MODIFY_BANDWIDTH request while being processing a bus reset (i.e. the 1394 SSCS entity 
started a bus reset and did not complete it yet, see clause 6.4), then an MODIFY_BAND WIDTH response shall be 
answered (with the status field set to RESET code). 

Else, if the IRM receives a MODIFY_B AND WIDTH request (asking for a modified bandwidth in a specified channel), 
it shall check if it is possible to modify such bandwidth on the requested channel. This exact procedure is out of the 
scope of the present document. 

If the modification of the bandwidth is correctly done, the IRM shall send a MODIFY_B AND WIDTH response, with 
the status field set to DONE code. It shall also update the bandwidth in the IRM (the exact procedure is out of the scope 
of the present document). It shall then send the RLC_DM_MC_MODIFY message to the CC to modify the multicast 
connection. 

If the modification of the bandwidth is not correctly done, the IRM shall send an MODIFY_BANDWIDTH response, 
with the status field set to the appropriate failure code. 

Note: a new listener may also be connected to an existing channel, without claiming for new resources on the IRM. This 
will appear to the IRM by an RLC_GROUP_JOIN message. The IRM shall then setup the multicast DLC connection 
corresponding to the 1394 channel towards this new listener. 

Resource reclaim (RECLAIM_THIS): 

When the CC side of the 1394 SSCS entity receives a BUS_RESUME information element contained in the 
RLC_INFO message, as defined in the bus reset procedure in clause 6.4, it shall release the bandwidth and channel 
registers and start a T timer (T = 1 s + AT). 

When the IRM receives a RECLAIM_THIS request (asking for a resource reclaim), it shall update the channel and the 
bandwidth and set the corresponding resources as reclaimed. 

As already said any command different than a RECLAIM_THIS shall be rejected by sending the corresponding 
command in a lock response (with the status field set to RESET code). 

If the re-allocation of the resources is done, it shall send a RECLAJM_THIS response, with the status field set to DONE 
code. 

If the re-allocation of the resources is not correctly done, it shall send a RECLAIM_THIS response, with the status field 
set to the appropriate failure code. 

When the timer T expires, unreclaimed resources are released (Group macJDs are released in the CL). The IRM shall 
then initiate a multicast release procedure toward the talker and each listener of these Group macJDs. 
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Resource release (RELEASE_THIS): 



If the CC receives a RELEASE_THIS request, while being processing a bus reset (i.e. the CC started a bus reset and did 
not complete it yet, see clause 6.4), then a RELEASE_THIS response shall be answered (with the status field set to 
RESET code). 

When the IRM receives a RELEASE_THIS request, (asking for a release of an isochronous connection), it shall free the 
reserved channel and bandwidth. It shall also send an RLC_DM_MC_RELEASE message for the corresponding 
multicast mac_ID. 

If the multicast release procedure succeeds, it shall send a RELEASE_THIS response, with the status field set to DONE 
code. 

Otherwise, it shall send a RELEASE_THIS response, with the status field set to a failure code. 

6.10 Asynchronous streams connection control service 
6.1 0.1 IRIVI and PCR functions 

IRM and PCR functions are used as described in clause 6.9 with some specificity: 

• As described in [7], a channel number has to be reserved by a 1394 controller without any bandwidth. This shall 
be done using the ALLOCATE_SOME lock request (as described in clause A.4) with no bandwidth. No PCR is 
defined in [7] for asynchronous streams. Nevertheless, when a WT wants to connect to an asynchronous stream, 
it shall behave as described in clauses 6.9.2.2 and 6.9.2.3, assuming the lock request in the PCR is received from 
its upper layer. 



• 



• 



After WTs have joined, the IRM does not perform any RLC multicast DLC connection setup. WTs are allowed 
to use the asynchronous stream as soon as they have joined the channel. 

One channel is reserved for global broadcast (see in table 13). Every WT shall join the global broadcast channel 
during the initialization. 



6.10.2 Asynchronous stream relaying 

6.10.2.1 General 

In the case some WTs do not have any radio contact between them, correctness of higher layer rely on a relaying 
mechanism for asynchronous stream data. This shall be done as described below. 

There is a distinction between the main channel and the forwarding channel. 

The main channel is defined by an IEEE 1394 [6] channel number. It is identified in the CHANNEL information 
element with the relay bit set to 0. A multicast mac_ID is defined and associated to the main channel. Any WT is 
allowed to send data in the main channel. Any WT, belonging to the main multicast group is allowed to listen 
and receive data from the main channel. 

The forwarding channel is defined by the same IEEE 1394 [6] channel as the main channel. It is identified in the 
CHANNEL information element with the relay bit set to 1 . When used, a specific multicast mac_ID is defined 
and associated to it (different from the main channel multicast mac_ID). The 1394 SSCS entity of the CC has to 
repeat on the forwarding channel any data sent on the main channel. 

6.10.2.2 Procedures 
6.10.2.2.1 Procedure in the WT side 

When a WT fails in receiving data from one sender on the main multicast channel carrying an asynchronous stream (a 
IEEE 1394 [6] channel with no bandwidth), it shall ask to join the forwarding channel. 

It shall send an RLC_GROUP_JOIN message containing the CHANNEL information element defined below to the CC. 
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Information element 


Reference 


Status 


Total length 
(octets) 


Description 


CHANNEL 


7.4.6 


mandatory 


3 


Channel set to forwarding channel number; 
relay bit set to 1 



The CHANNEL information element shall be transmitted in the «CL-ATTRIBUTE» field of the 
RLC_GROUP_JOIN message and the RLC_GROUP_JOIN_ACK response. 

6.10.2.2.2 Procedure in the CC side 

When at least one WT has asked to join the forwarding channel, the 1394 SSCS entity of the CC has to allocate a 
multicast mac_ID for the forwarding channel. 

The CC shall send an RLC_GROUP_JOIN message, with the allocated mac_ID, containing the CHANNEL 
information element defined below to the WT. 



Information element 


Reference 


Status 


Total length 
(octets) 


Description 


CHANNEL 


7.4.6 


mandatory 


3 


Channel set to forwarding channel 

number; 

relay bit set to 1 



The CHANNEL information element shall be transmitted in the «CL-ATTRIBUTE» field of the 
RLC_GROUP_JOIN and the RLC_GROUP_JOIN_ACK messages. 

It shall then repeat in the forwarding channel any data received in the main channel. 

The forwarding multicast group is released when the last WT left the forwarding multicast group. 

7 Convergence layer specific parameters 



7.1 Convergence layer identifier 



The convergence layer ID field of the convergence layer IE, defined in [2], shall be set according to table 10 to signal 
the support of 1394 SSCS in the WT and AP. The first 3 bits identifies the convergence layer. In case of the Packet 
based CL the next 5 bits identifies the Service Specific Convergence Sublayer. 

Table 10: convergence layer identifier 
Bits 8 7 6 5 4 3 2 1 Meaning 



10 1 1 394 SSCS supported 

All other values reserved 



7.2 Convergence layer version 



The convergence layer version number is an 8-bit field used in the RLC [2]. This field is split into two 4-bit subfields. 
The four most significant bits (bits 5 to 8) identify the version of the Common Part and the four least significant bits 
(bits 1 to 4) identify the version of the SSCS. The convergence layer version number shall be set according to table 1 1 
to indicate the support of this edition (version 1) of the 1394 SSCS. 

Table 1 1 : convergence layer version 
Bits 87654321 Meaning 



xxxxOOO 1 



1394 SSCS version 1 supported 
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7.3 



Maximum transmission unit 



The maximum transmission unit (MTU) used in the Common Part of the Packet based Convergence Layer [1] shall be 
set to 12 432 octets. 



7.4 



Information elements for 1394 SSCS 



7.4.1 



Information element format 



In order to transfer convergence layer specific information between CC and WT, as well as between two WTs, a 
number of CL information elements are defined. These convergence layer specific information elements are transferred 
transparently by RLC messages within the RLC specific field «CL-ATTRIBUTES», as defined in [2]. 

Each convergence layer information element consists of a type field, a length field and an information field, as defined 
in figure 16. 

The purpose of the information element type is to identify the function of the information element being sent. The IE 
type field is 8 bits, allowing for up to 256 information elements to be defined for a certain SSCS. 

The reserved field is for future use and shall be coded as zero. 

The length field indicates the length of the information field in bytes. It does not include the length of the IE type field, 
the reserved field, or the length of the length field itself. 





8 1 7 


1 6 


1 5 1 4 1 3 


1 2 


1 1 


Octet 1 


type 


Octet 2 


reserved 




lengtii = L 






Octet 3 


information 




Octet L+2 



Figure 16: convergence layer information element structure 



7.4.2 Information element type coding 

The IE type codes of table 12 are used in the 1394 SSCS: 



Table 12: information element fype coding 



IE Type code 


IE Name 


0000 0001 2 


HARP REQUEST (see clause 7.4.3) 


0000 001 O2 


HARP_RESPONSE (see clause 7.4.4) 


0000 0011 2 


EUl 64 (see clause 7.4.5) 


000001002 


CHANNEL (see clause 7.4.6) 


000001012 


BUS SUSPEND (see clause 7.4.7) 


000001102 


BUS RESUME (see clause 7.4.8) 


000001112 


BUS RESET (see clause 7.4.9) 


000010002 


TRANSACTION INDICATOR (see clause 7.4.1 0) 



All other values reserved for future lEs. 
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The «HARP_REQUEST» information element is used in the HARP. 



ETSI TS 101 493-3 VI .2.1 (2001-12) 





8 1 7 


6 


1 5 1 4 1 3 


1 2 


1 1 


Octet 1 


«HARP REQUEST» 


Octet 2 


reserved 




length = 2 






Octet 3 


bus ID[9..2] 


Octet 4 


bus_ID[1..0] 


reserved 



Figure 17: HARP_REQUEST information element 



7.4.4 HARP_RESPONSE information element 

The «HARP_RESPONSE» information element is used in the HARP. 





8 1 7 1 


6 1 5 1 4 1 3 1 


2 1 1 


Octet 1 


«HARP_RESPONSE» 


Octet 2 


reserved 


length = 3 




Octet 3 


bus ID[9..2] 


Octet 4 


bus_ID[1..0] 1 


physicalJD 




Octet 5 




reserved 


1 fwd 



Figure 18: HARP_RESPONSE information element 

7.4.5 EUI_64 information element 

The «EUI_64 » information element is used to inform the CC of the WT's EUI-64 during association. 

The node type informs the CC if the node is a bridge or not. The value indicates a non-bridge node. Other values 
indicate a bridge node. 





8 1 7 1 ( 


5|5|4|3|2|1 


Octet 1 


«EUI 64» 


Octet 2 


reserved 


length = 9 




Octet 3 


QUID 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 


Octet 1 


Octet 1 1 


nodejype 



Figure 19: EUI_64 information element 

7.4.6 CHANNEL information element 

The «CHANNEL» information element is used in the multicast join procedure. It is used by the WT to inform the 
CC about the channel number. It is also used in the asynchronous streams connection control service in the stream 
relaying procedure. 





8 1 7 


1 6 1 5 1 4 1 3 


1 2 


1 1 


Octet 1 


«CHANNEL» 


Octet 2 


reserved 


length = 1 






Octet 3 




channel 


relay 


reserved 



Figure 20: CHANNEL information element 

The relay field makes the distinction between the main channel and the forwarding channel, as defined in clause 6.5.3.2. 

The values of the channel are defined in table 13. The c [0] to c [31] bits specify the isochronous channel that is 
concerned. 
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Table 13: Values of the channel 



Value 


Status 


C [0] to C [29] 


Asynchronous and isochronous stream 


CfSOl 


Clock channel 


C[31] 


Global broadcast 


C [32] to C [47] 


Reserved 


C [48] to C [63] 


Error, see annex A 



7.4.7 BUS_SUSPEND information element 

The «BUS_SUSPEND» information element is used in the self-identity process. It is used by the CC to inform WTs 
about the start of the bus reset phase. 





8 1 7 


1 6 


1 5 1 4 1 3 


1 2 


1 1 


Octet 1 


«BUS_SUSPEND» 


Octet 2 


Reserved 




length = 







Figure 21 : BUS_SUSPEND information element 

7.4.8 BUS_RESUME information element 

The «BUS_RESUME» information element is used in the self-identity process. It is used by the CC to inform WTs 
about the completion of the bus reset phase. 





8 1 7 1 


6 1 5 1 4 1 3 1 2 


1 1 


Octet 1 


«BUS_RESUME» 


Octet 2 


reserved 


length = 2xN+1 




Octet 3 




reserved 


1 toggle_bit 


Octet 4 


mac ID(ofthelRM) 


Octet 5 


nodejype 


physical_ID{ofthelRM) 




Octet 6 


mac ID 


Octet 7 


node type 


physical ID 








Octet 2xN+2 


mac ID 


Octet 2xN+3 


nodejype 


physicalJD 





Figure 22: BUS_RESUME information element 

Fields shall be as follows: 

A^ shall be the number of wireless nodes in the HL2 Bus. N shall not be greater than 20. 

toggle_bit shall be set to 1 when all non-assigned physical_IDs have been recycled (marked as new) and at least 
one of them reassigned. 

node-type shall be the same as delivered by the upper layer in the CL_SELF_ID primitive (see clause 6.2.2). 

The first two bytes of the list shall contain information related to the IRM. 

7.4.9 BUS_RESET information element 

The «BUS_RESET» information element is used in the self-identity process. It is used by the WT to initiate a bus 
reset. 





8 1 7 


1 6 


1 5 1 4 1 3 1 


2 1 1 


Octet 1 


«BUS RESET» 


Octet 2 


reserved 




length = 3 




Octet 3 






reserved 


1 ewphyJD 


Octet 4 


mac ID 


Octet 5 


nodejype 




physicalJD 





Figure 23: BUS_RESET information element 

If new_phy_ID is set to one the CC shall assign a new physicalJD to the WT that initiates the bus reset. 
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The mac_ID, node_type and physical_id fields are those of the WT that initiates the bus reset. 

7.4.10 TRANSACTIONJNDICATOR information element 

The «TRANSACTION_INDICATOR» information element is used in the DLC user connection control process, 
when a DLC connection is setup for a 1394 transaction data service. 





8 1 7 


16 15 14 13 


1 2 


1 1 


Octet 1 


«TRANSACTION INDICATOR» 


Octet 2 


reserved 


length = 1 






Octet 3 




reserved 




request 



Figure 24: TRANSACTIONJNDICATOR information element 

The values of the request bit are specified in table 14: 

Table 14: requesf values 



request 


Name 


Cause 





REQUEST 


Initiating transaction is a requester 


1 


RESPONSE 


Initiating transaction is a responder 
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Annex A (normative): 
HIPERLAN/2 CSRs 



The intent of the present document is to isolate the higher level 1394 applications from the physical nature of the HL2 
DLC and PHY characteristics, so that only minor changes are required when porting an application from wired 1394 to 
wireless 1394. However, there are still several differences, due to 1394 physical related CSRs that are meaningless for a 
HL2 bus, as well as some specificity from the wireless medium that have been minimized (new lock format for IRM 
registers). 



A.1 CSR registers 

A.1 .1 Standard CSR registers 

For HL2 Bus, the standard CSRs of table A.1 shall be implemented. 

NODE_IDS, MESSAGE_REQUEST and MESSAGE_RESPONSE registers are the same as defined in wired 1394. 

SPLIT_TIMEOUT, CYCLE_TIME and BUS_TIME register format is the same as in wired 1394, but their exact usage 

is defined hereafter. 

INTERRUPT_TARGET, LOCAL_SECONDS and LOCAL_CYCLES registers (shaded in table A.1) are additional 

registers that are not specified by wired 1394. 

Other wired 1394 defined CSRs are not relevant for HL2 (as described in clause A. 1.2) and shall not be implemented. 

Table A.1 : Standard CSR registers 



offset 


register 


reference 


description 


8l6 


NODEJDS 


[6] 


Address selection 


18i6 


SPLIT_TIMEOUT 


A.1.8 


Local-bus split-response timeout 


50,6 


INTERRUPT_TARGET 


A.1. 3 


Controller event register 


5C,6 


LOCAL_CYCLES 


A.1. 6 


Local-bus free-running timer (LSBs) 


58,6 


LOCAL_SECONDS 


A.1. 7 


Local-bus free-running timer (MSBs) 


80,6 


MESSAGE_REQUEST 


[6] 


Message request register 


C0,6 


MESSAGE_RESPONSE 


[6] 


Message-response register 


200,6 


CYCLE_TIME 


A.1. 4 


Net-synchronous isochronous timer (MSBs) 


204,6 


BUS_TIME 


A.1.5 


Net-synchronous isochronous timer (LSBs) 



Except for the INTERRUPT_TARGET, LOCAL_CYCLES and LOCAL_SECONDS registers, the locations and 
formats of these registers are specified by the CSR Architecture. These offset addresses are also listed here, for the 
convenience of the reader; in the case of a definition conflict, the CSR Architecture shall have precedence. 
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A.1 .2 Unimplemented wired-1 394 registers 

The 1394-1995 and 1394a-2000 bus dependent registers, defined in [6] and [7] respectively, which are listed below 
shall not be implemented: 



1394-1995 registers: 

POWER_FAlL_lMMINENT 

POWER_SOURCE 

BUSY_TIMEOUT 

BUS_MANAGER_ID 

BANDW1DTH_AVA1LABLE 

CHANNELS_AVA1LABLE 

MA1NT_C0NTR0L 

MA1NT_UT1L1TY 

TOPOLOGY_MAP 

SPEED_MAP 

1394a-2000 registers: 

PR10R1TY_BUDGET 
BROADCAST_CHANNEL 



- Only applicable to backplane shared power-supply designs 

tt 

- Managed by end-to-end timeout 

tt 

- Replaced by message-based IRM 

tt 

- Unnecessary and not applicable 

- Unnecessary and not applicable 

- Unnecessary and not applicable 

- Unnecessary and not applicable 

- Not used 

- Unnecessary 



A.1 .3 INTERRUPT_TARGET register 

All isochronous controllers shall implement this register. 

This register provides a target address for sending of interrupt-event indication to the controller portion of a node. A 
quadlet write transaction data corresponds to 32 events that can be signalled. Only one of these events is specified (this 
corresponding to the least-significant bit of this register), as illustrated in figure A. 1 . 



definition 



reserved 
_] I I I I I I I I I I I I I I I I I I I I I I I I I I I I I J. 



disconnected_pcr 



read value 



zeros 

_i I I I I I I I I I I I I I I I I I I I I I I I I I I I I I i_ 



write effects 



ignored 

L 



J I I I I I I I I I I I I I I I I I I I I I I I I I I I I L 



_L 



event indication ' 

Figure A.1 : INTERRUPT_TARGET register 

A quadlet write with disconnected_pcr bit set to one indicates that the requesting node has been disconnected from an 
isochronous stream and that PCR has been updated. That write shall be ignored if the disconnected_pcr bit is zero. 



A.1 .4 CYCLE_TII\/IE register 



Distinction: This register is read-only. 

Distinction: This register is updated once each 2 ms frame, rather than once every 125 )is cycle. 

Distinction: The synchronizing clock-master node is not necessarily the IRM. 

All nodes capable of providing isochronous services shall implement this register. The implementation is optional for 

nodes that do not provide isochronous services. 
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Nodes that are isochronous capable shall implement a clock that shall run freely and shall update the contents of the 
CYCLE_TIME register. The CYCLE_TIME register shall also be updated, once each 2 ms frame, to the 
clock-reference value implied by values transmitted within frames. The fields within the CYCLE_TIME register specify 
the current time value, in a 1394 compatible fashion, as illustrated in figure A.2. 



definition 



Seconds_count 


cycle_count 


cycle_offset 


power-reset vaiue 


zeros 

1 1 1 


bus-reset and command-reset vaiues 


unchanged 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


read vaiues 


last update 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


write effects 


ignored 
1 1 1 



Figure A.2: CYCLE_TII\flE register 

The 7-bit second_count field is an exact copy of the 7 least significant bits of the BUS_TIME register. 
The 13-bit cycle_count field specifies the time offset from the last integer second value, in units of 125 )is. 

The 12-bit cycle _off set field specifies the time offset from the last integer cycle_count value, in units of 
125 )is / (2 048 + 1 024). This prevision corresponds to one tick of a 24,576 MHz clock. 



A.1.5 BUS_TIME register 



Distinction: This register is read-only and is updated by the clock-master node once each 2 ms frame. All nodes capable 
of providing isochronous services, and then implementing the CYCLE_MASTER register, shall implement this register. 
The implementation is optional for nodes that do not provide isochronous services. 

Nodes that are isochronous capable shall implement a clock that shall run freely and shall update the contents of the 
BUS_TIME register. The BUS_TIME register shall also be updated, once each 2 ms frame, to the clock-reference value 
implied by values transmitted within frames. The BUS_TIME register specifies the current time value, in seconds, as 
illustrated in figure A. 3. 
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definition 



seconds 

_i I I I I I I I I I I I I I I I I I I I I I I I I I I I I I i_ 



power-reset vaiue 



zeros 

_i I I I I I I I I I I I I I I I I I I I I I I I I I I I I I i_ 



bus-reset and command-reset vaiues 



unchanged 
_i I I I I I I I I I I I I I I I I I I I I I I I I I I I I I i_ 



read vaiues 



last update 

_i I I I I I I I I I I I I I I J I I I I I I I I I I I I I I i_ 



write effects 



ignored 
_i I I I I I I I I I I I I I I I I I I I I I I I I I I I I I i_ 



Figure A.3: BUS_TII\flE register 

The 32-bit seconds field provides a measure of the current time in seconds and has a range of 2^^ seconds, or 
approximately 136 years. 

A.1 .6 LOCAL_CYCLES register 

All nodes shall implement the LOCAL_CYCLES register. This register provides access to a local-synchronized clock 
value. This clock is provided to support asynchronous split-response timeouts. 

The fields within this register specify the current time value, in a CYCLE_TIME compatible fashion, as illustrated in 
figure A. 4. 





definition 




seconds_count 


cycle count 
1 1 , , , 


cycle offset 
... 1 


power-reset value 


zeros 


bus-reset and command-reset values 


unchanged 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


read values 


last update 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


write effects 


ignored 
1 1 1 



Figure A.4: LOCAL_CYCLES register 

The 7-bit second_count field is an exact copy of the 7 least significant bits of the LOCAL_SECONDS register. 

The 13-bit cycle_count field specifies the time offset from the last integer second value, in units of 125 )is. 

The 12-bit cycle _off set field specifies the time offset from the last integer cycle_count value, in units of 
125 )is / (2 048 + 1 024). This prevision corresponds to one tick of a 24,576 MHz clock. 
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The behaviour of this register depends on a node's clock-master capabihties, as follows: 

a) Clock-master. The clock-master node, based on its free running clock, asserts its time value every 2 ms frame, 
for the purpose of synchronizing non clock-master nodes. 

b) Non clock-master. This register shall be updated, once each 2 ms frame, based on the clock-reference value 
transmitted by the clock-master node within frames. Between these updates this register is autonomously 
increased by the node. 



A.1 .7 LOCAL_SECONDS register 



All nodes shall implement the LOCAL_SECONDS register. The fields within this register specify the current time value, 
in a BUS_TIME compatible fashion. The register specifies the current time value, in seconds, as illustrated in 
figure A. 5. 



definition 



seconds 

_i I I I I I I I I I I I I I I I I I I I I I I I I I I I I I i_ 



power-reset value 



zeros 

_i I I I I I I I I I I I I I I I I I I I I I I I I I I I I I i_ 



bus-reset and command-reset values 



unchanged 
_i I I I I I I I I I I I I I I I I I I I I I I I I I I I I I i_ 



read values 



last update 

_i I I I I I I I I I I I I I I J I I I I I I I I I I I I I I i_ 



write effects 



ignored 
_i I I I I I I I I I I I I I I I I I I I I I I I I I I I I I i_ 



Figure A.5: LOCAL_SECONDS register 

The 32-bit seconds field provides a measure of the current time in seconds and has a range of 2^^ s, or approximately 
136 years. 

The behaviour of this register depends on a node's clock-master capabilities, as described in clause A. 1.6. 



A.1 .8 SPLIT_TIMEOUT register 



Distinction: the initial value of this register corresponds to 200 ms, as opposed to the initial wired- 1394 100 ms value. 
Distinction: the measurement points and the duration of timeouts differ from 1394, see clause C.2. 
All nodes shall implement this register. 

Split-transaction error detection expects all HL2 Bus nodes to share the same time-out value and that requester and 
responder behave in complementary fashion, as specified in clause C.2. The SPLIT_TIMEOUT register establishes the 
time-out value for the detection of split-transaction errors, as illustrated in figure A.6. 
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definition 



reservedO 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


sec 

1 1 


cycles 

1 1 1 1 1 1 1 1 1 1 1 1 


reservedl 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


power-reset value 


zeros 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


1600,„ 


zeros 

. . 1 1 


bus-reset and command-reset values 


unchanged 


unchanged 


read values 


zeros 


Iw 


last-write 

1 1 1 1 1 1 1 1 1 1 1 1 


zeros 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


write effects 


ignored 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


stored 

1 1 


stored 

1 1 1 1 1 


ignored 
III 1 



Figure A.6: SPLIT_TIMEOUT register 

The 3-bit sec field, in units of seconds, and the 13-bit cycles field, in units of 125 |is, together specify the time-out 
value. The value of cycles shall be less than 8 000. 

The minimum time-out value is 1 600 cycles (0,2 s). If a value smaller than this is written to the SPLIT_TIMEOUT 
register the node shall not revise the stored value but shall behave as if a value of 1 600 had been stored. 

NOTE: The Serial Bus definition of the SPLIT_TIMEOUT register differs from that of the CSR Architecture. 
Serial Bus interprets the most significant 13 bits of the SPLIT_TIMEOUT_LO register as units of 
1/8 000 s, rather than a true binary fraction of a second with units of 1/8 192 s. Since precise time-outs are 
not necessary, the bus manager may ignore this difference when calculating values for use within the 
SPLIT_TIMEOUT_LO register. 



A.2 PCRs 
A.2.1 oPCR format 

Distinction: The oPCR payload contents are specified differently and include bus-dependent overhead. 

The oPCR is specified in clause 7.7 of the lEC 61883 [5], part 1. 

The usage of the oPCR is the same as described in lEC 61883 [5], part 1, with the addition that some HL2 specific error 
codes are specified in the present document. These HL2 specific error codes (see clause A. 2. 3) are used in the PCR lock 
response to indicate an error to the initiating controller. 
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The format of the HL2 oPCR is also sHghtly different from the lEC 61883 [5] oPCR (as described below). 
The oPCR is depicted in figure A. 7. 



definition 



_i I I I i_ 



res 



channel number 
I I I I I 



reserved 



_i I I I i_ 



payload 



_i I I I I I I I i_ 



point-to-point connection counter 



broadcast connection counter 



on-line 









power-reset value 




zeros 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


bus-reset and command-reset values 


- 


zeros 

1 1 1 1 1 1 1 


unchanged 

1 1 1 1 1 


zeros 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 


iinnhangpri 








read values 


last update 


00 


last-update 


zeros 


unchanged 
.1 


write effects 


ignored 
1 1 1 



Figure A.7: oPCR format 

The on-line bit always indicates whether the corresponding output plug is on-line (value one) or off-line (value zero). 

The broadcast connection counter bit indicates whether a broadcast-out connection to the output plug exists (value 
one) or not (value zero). 

The 6-hit point-to-point connection counter indicates the number of point of point connections to the output plug. 

The 6-bit channel number indicates the actual channel number used by the output plug. 

The lO-hit payload reflects the maximum number of bytes to be transmitted within a 2 ms HL2 frame (including the 
SSCS and CPCS overheads) divided by 16. 

The HL2 Bus 500 Hz (± 20 ppm) physical layer framing clock is not synchronized to the wired- 1394 8 kHz 
(± 100 ppm) cycle clock. To account for the clock deviations, the application shall add a 1-byte margin to the 
oPCR.payload value. 

A.2.2 iPCR format 

The iPCR is specified in clause 7.8 of the lEC 61883 [5], part 1. The format of the iPCR is depicted in figure A. 8. 

The usage of the iPCR is the same as described in lEC 61883 [5] part 1, with the addition that some HL2 specific error 
codes are specified in the present document. These HL2 specific error codes (see clause A. 2. 3) are used in the PCR lock 
response to indicate an error to the initiating controller. 
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definition 
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- 
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power-reset value 
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unchanged 
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read values 



last update 


00 


last update 


zeros 


write effects 


ignored 
1 1 1 



Figure A.8: iPCR format 

The definition of the fields is the same as in the oPCR. 

The on-line bit, the broadcast connection counter bit, the 6-hit point-to-point connection counter field, and the 6-bit 
channel number field are described in lEC 61883 [5], clause 7.8 of part 1. 

A.2.3 PCR error codes 

Lock transactions on PCRs can fail due to HL2 specific reasons, as described in clause 6.9.2.2 and in clause 6.9.2.3. 
Therefore some specific channel numbers are reserved for that purpose (see clause 7.4.6). When an error occurs, these 
reserved channel numbers shall be used in the lock response, as defined in table A.2. 

Table A.2: PCR error codes 



Channel value 


Name 


Description 


62 


TRANSIENT ERROR 


A non fatal error occurred 


63 


PERSISTENT ERROR 


A severe error occurred 



When a TRANSIENT_ERROR is reported, the 1394 controller is expected to retry the lock request on the PCR. 

When a PERSlSTENT_ERROR is reported, the 1394 controller is not expected to retry the lock request on the PCR 
until the error condition has been resolved. 
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A.3 ROM information 



The HL2 Bus provides 1394 services over an alternate (RF) physical layer. The bus_info_block has a distinctive "0000" 
label (to avoid possible confusion with wired- 1394), but is otherwise as specified by wired 1394. Other bus-directory 
entries are used to better identify the HL2 physical layer and its bus-dependent CSR behaviours, as illustrated in 
figure A.9. 
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Figure A.9: HL2-Bus ROM format 

The 8-bit bus_info_length field, the imc (isochronous resource manager capable) bit, cmc (cycle master capable) bit, 
isc (isochronous capable) bit, 8-bit cycle _clk_acc (cycle clock accuracy) field, 4-bit max_rec (maximum receive buffer 
size) field, and 2-bit max_ROM (maximum ROM access) fields are defined by wireless 1394. The bmc (bus manager 
capable) bit, pmc (power manager capable) bit, 4-hit generation field, and the 3-bit link_spd fields shall be zero. The 
quadletfA] .crc_length field shall have a value of 6 and the quadlet[A] .crc field shall cover the following 6 quadlets. 

A node that Is CC capable (as defined in [4] shall be isochronous resource manager capable, and thus shall set the imc 
bit to 1 . A node that is not CC capable (WT only) shall clear the imc bit to 0. 



£75/ 



60 ETSI TS 1 01 493-3 V1 .2. 1 (2001 -1 2) 

The 24-bit company _id identifies the vendor that administers the following chip_ID_hi and chip_ID_lo field values. 
The 8-bit chip_ID_hi and 32-bit chip_ID_lo values shall be concatenated to produce a 40-bit chip_ID value. 
The concatenation of the company _id and chip_ID values shall be the globally unique EUI-64 value for this node. 

The initial root-directory entry is a quadlet in size and points to a Bus_Dependent_Info directory; the 2-bit 
quadlet[G[.type field has a Directory=3 value; the 6-bit quadlet[G].key_id (key identifier) has a 

Bus_Dependent_Info=2 value, and the 24-bit quadlet[G].offset field specifies the number of quadlets between here and 
the start of the bus-directory directory. 

The first quadlet of the bus-directory has 16-bit quadletf J]. length and quadlet [ J ].crc fields, whose meanings are 
defined by like named fields in the CSR Architecture. The 2-bit quadlet[K].type field has an lmmediate=0 value; the 
6-bit quadlet[K].key_ld (key identifier) has a Specifier_ID=12i6 value; the 2-bit quadlet[L] .type field has an 
lmmediate=0 value; the 6-bit quadlet[K] .key _ld has a Version=13i6 value. 

The concatenation of the 24-bit quadlet[K]. specifier _ID and 24-bit quadletf L]. version fields forms the EUI-48 
identifier that uniquely specifies the HL21394 SSCS "bus" standard. The specifier_ID is the IEEE 802 
committee company _id value; the version field is a value administered by the the IEEE 802 committee. For the present 
document specification, these shall have the values listed below; 

company_id 0180C2i6 

version 000200i6 

The 2-bit quadlet[M] .type field has an lmmediate=0 value and the 6-bit quadlet[M].key_id field (key identifier) has a 
38i6 value to indicate that the following 24 bits identify the version of the present document. The 8-bit 
quadlet[M].SSCS_revision contains the revision number of the 1394 SSCS TS (TS 101 493-3). The 8-bit 
quadlet[M] .SSCS _phase contains the phase number of the 1394 SSCS TS (TS 101 493-3). The SSCS_phase and 
SSCS_revision fields shall be coded with major (m) and technical (a) version numbers respectively of the present 
document (m and a are defined in annex B of [8]). 

NOTE: No fields are allocated to represent editorial changes. 

The 2-bit quadlet[N] .type field has a Leaf=2 value and the 6-bit quadlet[N].key_id field (key identifier) has a 
Textual_Descriptor= 1 value. The 24-bit quadlet [N]. off set field specifies the number of quadlets between here and the 
start of the textual-descriptor leaf. 

The leading quadlet of the textual-descriptor leaf provides quadlet[P] .length and quadlet[P].crc fields, as specified by 
the CSR Architecture. The 8-bit quadlet[Q]. descriptor _type, 24-bit quadlet[Q]. specifier _ID8, 4-bit quadlet[R]. width, 
12-bit quadlet[R]. character _set, and 16-bit quadletf R]. language _id fields shall be zero (this identifies the remaining 
text to be in minimal ASCII English). The following text shall specify the "1394-HL2-SSCS" string, which corresponds 
to the 1394 SSCS TS (TS 101 493-3). 



A.4 Locked messages 



The HL2 Bus IRM interface differs from that defined by wired 1394, because isochronous bandwidth allocations 
depend on the talker_ID and listener_ID identifiers of the participating nodes. Since a different IRM interface is 
mandated, an efficient (as opposed to legacy-compatible) locked-message transport is provided. 

A locked-message exchange has two phases: call and return, where the call and return phases correspond to the request 
and response subactions of a distinctive lock transaction. The request provides a command byte and multiple 
command-dependent arguments; the response returns a status byte and multiple status-dependent extended-status bytes, 
as described in the remainder of this clause. 

The locked-message transaction is distinguished by its address-offset and lock-subcommand values. The address offset 
shall be the start of the MESSAGE_REQUEST register (see clause A. 1.1). The lock subcommand is the bus-dependent 
(value 7) value, as specified by the CSR architecture. 
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A.4.1 Locked message formats 



The locked-message components include a 16-byte request and 8-byte response packet payloads, as illustrated in 
figure A. 10. 



transmitted first 



request 



command 
_i I I I I I i_ 



_L 



dependentO 



_l I I I I I I I I I I I I I L. 



_l I I I I I 1_ 



dependenti 



_i I I I I I i_ 



_i I I I I I i_ 



_L 



J I I I I I i_ 



_i I I I I I i_ 



dependent2 



_i I I I I I I I I I I I I I I L 



J I I I I I L. 



_i I I I I I i_ 



dependents 



_i I I 1 I I 1 I I 1 I I 1 I I I I I 1 I I 1 I I 1 I I I I I i_ 



transmitted last 



transmitted first 



response 



status 



_i I I I I I i_ 



dependentO 
_i I I I I I I I I I I I I I I I I I I I I I i_ 



dependenti 



_i I I I I I i_ 



_i I I I I I i_ 



_L 



J I I I I I L. 



_l I I I I I L. 



transmitted last 



Figure A.10: Locked message formats 

The 8-bit command values specify the locked-message operation to be performed, as specified in table A.3. The 
definitions of status-field values is command-vs\\i& dependent. 

Table A.3: Locked-message co/n/nanc/ values 



Value 


Name 


Clause 


Description 





ALLOCATE SOME 


A.4.2 


Available channel{s) and bandwidth request 


1 


MODIFY BANDWIDTH 


A.4.3 


Modify isochronous bandwidth allocation 


2 


RECLAIM THIS 


A.4.4 


Isochronous reallocation, channel and bandwidth 


3 


RELEASE THIS 


A.4.5 


Isochronous release, channel and bandwidth 


4-255 


- 




Reserved 



A.4.2 ALLOCATE_SOME 

An available channel and isochronous bandwidth are allocated for communication between physical_ID-addressed 
talker_ID and listener_ID nodes, using the parameters illustrated in figure A.l 1. 
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Figure A.11 : ALLOCATE_SOME register format 
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A.4.2.1 ALLOCATE_SOME request 

The 8-bit command distinctively identifies this command (see table A.3). 

The 6-bit talker _ID and 6-bit listener _ID values specify the physical_ID addresses of the local talker and listener nodes 
respectively. 

The \0-\i\i payload value specifies the necessary isochronous bandwidth, as specified in clause A.2.1. 

A.4.2.2 ALLOCATE_SOME response 

The returned 8-bit status field indicates the success or failure of the command, as specified in table A.4. 

Table A.4: ALLOCATE_SOME response format 



Value 


Name 


Description 





DONE 


Successful completion 


1 


CHAN 


Channel allocation failure 


2 


RESET 


Bus reset in process 


3 


BW 


Isochronous bandwidth allocation failure 


4 


BOTH 


Channel and bandwidth allocation failure 


5-254 


- 


Reserved 


255 


BAD COMMAND 


Unsupported command 



The 8-bit handle field contains the allocated multicast mac_ID, which is needed on following same-channel IRM 
commands. 

The returned 6-bit channel value identifies the allocated isochronous channel number. 

A.4.3 MODIFY_BANDWIDTH 

The isochronous bandwidth associated with a specific channel is modified (increased or decreased), using the 
parameters illustrated in figure A. 12. 



transmitted first 




reqi 


jest 




command 
■ ''■■II 


1 1 1 1 1 1 1 


reservedO 

1 1 1 1 1 


1 1 1 1 1 1 1 1 1 


reserved 1a 


channel 


reservedlb 


payload 


reserved2 


reservedS 
1 // 1 1 1 1 1 1 1 1 1 1 // 1 1 1 1 1 1 1 I 1 1 1 1 1 1 1 1 



transmitted last 



transmitted first 


response 


status 

■ ' ' ■ ■ ■ ■ 


reservedO 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


reserved 1 
1 1 1 1 1 1 1 1 1 1 1 1 1 1 / 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 



transmitted last 



Figure A.12: MODIFY_BANDWIDTH register format 
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A.4.3.1 MODIFY_BANDWIDTH request 

The 8-bit command distinctively identifies this command (see table A.3). 

The 6-bit channel value identifies the isochronous channel number for which bandwidth is modified. 

The \0-h\i payload value specifies the necessary isochronous bandwidth, as specified in clause A.2.1. 

A.4.3.2 MODIFY_BANDWIDTH response 

The returned 8-bit status field indicates the success or failure of the command, as specified in table A.5. 
Table A.5: MODIFY_BANDWIDTH response-sfafus values 



Value 


Name 


Description 





DONE 


Successful completion 


1 


CHAN 


Channel failure 


2 


RESET 


Bus reset in process 


3 


BW 


Bandwidth modify failure 


4-254 


- 


Reserved 


255 


BAD COMMAND 


Unsupported command 



A.4.4 RECLAIM_THIS 

A specific channel and isochronous bandwidth are reclaimed, using the parameters illustrated in figure A. 13. 
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Figure A.13: RECLAIM_THIS register format 

A.4.4.1 RECLAIM_THIS request 

The 8-bit command distinctively identifies this command (see table A.3). 

The 8-bit handle value shall equal that returned by the initial ALLOCATE_SOME locked-message. 

The 6-bit channel value specifies the requested isochronous channel number. 

The \0-h\ipayload value specifies the necessary isochronous bandwidth, as specified in clause A.2.1. 
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A.4.4.2 RECLAIM_THIS response 

The returned 8-bit status field indicates the success or failure of the command, as specified in table A.6. 

Table A.6: RECLAIMTHIS response-sfafus values 



Value 


Name 


Description 





DONE 


Successful completion 


1 


CHAN 


Channel reclaim failure 


2 


RESET 


Bus reset in process 


3 


BW 


Bandwidth reclaim failure 


4 


BOTH 


Channel and bandwidth reclaim failure 


5-254 


- 


Reserved 


255 


BAD COMMAND 


Unsupported command 



A.4.5 RELEASE THIS 



A specific channel and isochronous bandwidth are released, using the parameters illustrated in figure A.M. 
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Figure A.I 4: RELEASE_THIS register format 

A.4.5.1 RELEASE_THIS request 

The 8-bit command distinctively identifies this command (see table A.3). 
The 6-bit channel value specifies the released isochronous channel number. 

A.4.5.2 RELEASE_THIS response 

The returned 8-bit status field indicates the success or failure of the command, as specified in table A.7. 

Table A.7: RELEASETHIS response-sfafus values 



Value 


Name 


Description 





DONE 


Successful completion 


1 


CHAN 


Channel release failure 


2 


RESET 


Bus reset in process 


3-254 


- 


Reserved 


255 


BAD COMMAND 


Unsupported command 
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Annex B (informative): 
Quadlet-structured PDU formats 



Within HL2 standards, the PDU formats are normally illustrated in byte-wide figures. For the convenience of 
wired- 1394 readers, this annex provides quadlet-wide equivalents of these figures. 

Fields of quadlet-wide PDUs are the same as those of the byte wide PDUs. See clauses 5.4.2, 5.5.1.2 and 5.5.2.2 for 
fields description. 
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Figure B.1 : Asynchronous subaction PDU format 



B.2 Isochronous streams 
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Figure B.2: Isochironous stream PDU format 
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Figure B.3: Isochronous tagged SDU 



B.3 Asynchronous streams 
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Figure B.4: Asynchronous stream PDU format 
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Annex C (normative): 
Nonbridge upper layer 



A wireless node that does not gather bridge functions may implement the 1394 SSCS only. In that case, the upper layer 
that is not a HL2 1394 bridge layer entity shall react as described in this annex. 

This annex contains informative as well as normative parts. 



C.1 Primitives (informative) 



The upper layer uses the primitives defined in clauses 5.2.1 and 6.2. They are adapted to the 1394 SSCS, and are 
slightly different from those provided by the 1394 link layer. 



C.2 Time stamps for split-response timeouts (normative) 

Split-responses buses, like wired 1394 or HL2 Bus, detect transmission failures through split-response timeouts. On the 
HL2 Bus, time stamps are used to limit the request-transmission time, the responder transaction processing time, and 
the response-transmission time. The requester normally abandons the transaction after the sum of these worst-case 
times, but avoids reuse of the transaction's tlabel identifier until an even later time, to cope with possible inaccuracies in 
transmission-time limits. 

The timeout requirements for wired 1394 and HL2 Bus are similar, but differ in where timing checks are performed, as 
illustrated in figure C.l. Although implementation details differ, both buses provide for a SPLIT_TIMEOUT responder- 
processing delay and a 2xSPLIT_TIMEOUT timeout recovery delay in the requester. 
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T3,: SPLIT_TIMEOUT register value 

to : request posted for transmission 

ti : request transmitted 

t2 : request available to responder 

ta : response posted for transmission 

t4 : response transmitted 

ts : response available for the requester 

te : tLabel recycling 



Figure C.1 : Split-response timeout times 

A wired-1394 request-transmission begins at time to and a busy-retry timeout limits the arbitration delay (t, - to) to a 
software-specifiable value. The t, transmission time of a request and the t4 transmission time of the response are visible 
to the requester and responder. The responder limits its processing time to ensure that (t4 - ti) < T^, and the requester 
terminates the transaction if (t4 - ti) > Ts,. To account for timing differences and, the requester avoids reusing the 
transaction tlabel identifier until time t^, where (tg - ti) > 2 X T^t. 
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HL2 Bus transmission times are not visible to the 1394 SSCS entity, so timeouts are defined in a different (although 
similar) fashion. A HL2 Bus request-transmission begins and ends at times to and t2 respectively, and a delay of l/2Ts,is 
allocated for this request-packet transmission. 

The responder is expected to limit its processing time to ensure that (t^ - 12) < l/2Tst. A response-transmission begins 
and ends at times t^ and tj respectively, and a delay of ViT^t is allocated for this response-packet transmission. 

The requester terminates the transaction when (ts - to) > (3/2) T^t but (to account for timing differences and 
irregularities) avoids reuse of a timed-out transaction's tlabel identifier until time tg, where (te - to) > 2Ts,. 

Time stamps on HL2 Bus packets effectively limit the lifetime of request and response packets. These time-stamp 
values are unknown to the lower-layer protocols, so actual lifetimes can exceed their allocated limits. The receivers are 
therefore responsible for checking received time-stamp values, so that stale packets can be discarded. 

To realize the desired behaviours, the processing of packet time-stamp values (see clauses 5.2.3.2.1 and 5.4.4) is 
specified as follows: 

a) Requester inclusion: the requester shall prepend its request packet with a time_of_life=(3/2)Tst. 

b) Responder rejection: when the request is received at time t2, a responder shall behave as follows: 

1) The request may be rejected if time_of_life < Tst (because the request transmission time has exceeded l/2Ts,). 

2) The request should be rejected if time_of_life < l/2Tst (to allow for a response transmission time of l/2Tst). 

c) Responder discard: the responder shall discard an in-progress request or response, if time_of_life < 0. 

d) Responder processing: when generating a response, the response time_of_life shall be set to the request 
time_of_life minus the response processing time (t3 - 12). 

NOTE 1 : This time_of_life calculation results in equal time_of_death values in both request and response 
asynchronous subaction SSCS PDUs (see clause 5.4.2). 

e) Requester discard: when received at time tj, the requester shall discard a response if time_of_life < 0. 

f) Requester recycle: a requester may release a tlabel when the first of the following occurs: 

1) Completion: matching response is received. 

2) Termination: (te - to) > 2Ts, 

NOTE 2: Some of the data can still be in the lower layer when the current bus time exceeds the PDU specified 
time_of_death. Then the discarding facilities of the DLC (see [3]) may be used to avoid transmitting 
useless data. The details of this mechanism are implementation dependent and outside the scope of the 
present document. 



C.3 User plane 

C.3.1 Isochronous stream transport service 

C.3.1 .1 HL2 Bus maximum transmission delay (informative) 

The receiver of isochronous streams shall be prepared for these streams to experience a maximum transmission delay of 
6,1 ms. 

The example on figure C.2 shows how consecutive channel traffic on wired 1394 are concatenated over a duration of 
approximately 2 ms. The MAC frame top signals are generated by the appropriate primitive. 

It is assumed that the 1394 SSCS collects all data of each cycle until it receives this frame top. But the 

wired 1394 8 kHz cycle clock is not synchronized on the 500 Hz HL2 Bus clock. Thus the concatenation can reach 

17 cycles of 125 |is. 



£75/ 



69 



ETSI TS 101 493-3 VI .2.1 (2001-12) 



In figure C.2, a fixed number of slots is reserved in each frame starting at position #Q (fixed capacity agreement). 

The 16 (15 or 17) wired 1394 cycle data acquired are dealt by the 1394 SSCS, CPCS and SAR and provide N packets of 
48 bytes. These bytes are encapsulated by the DLC and transmitted in the slots reserved on the air interface. 

The maximum transmission jitter is 6,1 ms, coming from: 

• 2,1 ms for the worst case acquisition period over one MAC frame: in the normal case it is 2 ms, but due to the 
1394 clock/HL2 clock difference, a 1394 SSCS PDU may sometimes contain 17 SDUs (see clause 5.5.1.2), and 
thus the acquisition period may contain an additional 1394 cycle (0,1 ms); 

• 2 ms because the granted slot may have just occurred when the corresponding data come to the DLC, so that it 
shall wait for the next frame (worst case 2 ms); 

• 2 ms because the scheduler may have rescheduled the frame at that point, so that the slot is now at the other side 
of the frame (worst case 2 ms). 

NOTE: As already mentioned, a 1394 SSCS entity may generate 16-SDU PDUs in average, and sometimes a 

17-SDU PDU. As mentioned in clause A.2.1, a secure margin shall be reserved by 1394 controller to take 
the 1394/HL2 clock difference. Nevertheless, when a 17-SDU PDU is transmitted, the last SDU of the 
17-SDU PDU (or at least part of it) may have to wait for the next frame (because the other 16 SDUs have 
already used all granted slots). The 17* SDU may thus experience a 2 ms more transmission delay. But, 
since it did not experience any acquisition delay (the PDU has been completed with it), no specific 
additional delay is taken into account here. 
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Figure C.2: maximum transmission delay 

C.3.1 .2 Relative CIP time stamps (normative) 

On wired 1394, CIP headers transport an absolute time stamp. The time stamp is either located in the SYT field of the 
CIP header or located in a subsequent Source Packet Header, respectively. The meaning is described in lEC 61883 [5]. 

When isochronous packets are transmitted via HL/2 a relative time stamp shall replace the cycle information of the 
absolute time stamp. This relative time stamp indicates how many cycles in advance to the originally intended 
presentation time a packet is posted to the transmitting 1394 SSCS. The cycle offset field of the time stamp shall remain 
unchanged. 
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Depending on the CIP data format, the time stamp may be located in the SYT field of the CIP Header or in the Source 
Packet Header, as illustrated in figure C.3 and figure C.4. These figures illustrate tagged SDUs as specified in 
clause 5.5.1.2. On the HL2 Bus, the format of these isochronous payloads is the same, but a relative time stamp 
replacing the cycle field of the absolute time stamp shall be provided. 

A 4-bit cCount time-stamp field can be located in the CIP header, as illustrated in figure C.3. 
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Figure C.3: CIP header time stamp 

The value of cCount in an HL2 Bus packet (hl2Bus. cCount) can be readily derived from the value defined by 
lEC 61883 [5] for the CIP header (cipStd. cCount), and shall be as specified below; 

hl2Bus.cCount = (cipStd.cCount - time_stamp.cycles)&OxF; 
where: 

time_stamp is a parameter of the CL_ISOCH_STREAM primitive, which specifies the isochronous cycle when 
the isochronous packet is presented to the 1394 SSCS. 

Alternatively, a 13-bit cycle_count time-stamp field can be located at header-dependent positions within transmitted 
data blocks, as illustrated in figure C.4. 
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Figure C.4: Source packet header time stamps 

The value of cycle_count in an HL2 Bus packet {hl2Bus.cycle_count) can be readily derived from the value defined by 
lEC 61883 [5] for the CIP header {cipStd.cycle_count), and shall be as specified below: 

hl2Bus.cycle_count= (8000 + cipStd.cycle_count - time_stamp.cycles) % 8000; 
where: 

time_stamp is a parameter of the CL_ISOCH_STREAM primitive, which specifies the isochronous cycle when 
the isochronous packet is presented to the 1394 SSCS. 

Note that the replacement of an absolute time stamp by a relative time stamp will require the recalculation and 
replacement of the data CRC. 

The relative time stamp information may be used to achieve a constant delay system over the wireless bus. 

C.3.2 Asynchronous transactions 
C.3.2.1 Subaction rt field (normative) 

If the packet originated on wired 1394 and passed through a bridge, the rt field and the header _CRC values shall be the 
values that were observed on the bus when the packet was received. Except for its inclusion in the headerjCRC 
calculation, the value of the rt field shall be ignored. If the request packet passes through wireless 1394 and returns to a 
wired 1394 environment, the wired- 1394 specified rt field value shall be used. Since the transmitted rt value may 
change, wired- 1394 transmitters are required to recompute the headerjCRC value while the packet is being transmitted. 

If the packet is originated from a HL2 Bus node, the rt field shall be zero. 

All asynchronous packets are prepended with the same seconds/cycles quadlet and transmitted as received on 1394. For 
the sake of brevity, these other packet formats are not illustrated. 
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C.3.2.2 Available self-ID information (informative) 

The HL2 Bus self-ID information includes a 2-bit node_type field, a 6-bit physical_ID field, and an 8-bit mac_ID field 
for each of the attached nodes. The IRM information block is always the first of these, allowing the IRM node to be 
readily identified. See clause 7.4.7 for details. 



C.4 Control plane (normative) 
C.4.1 Clock connection control 

The upper layer shall not generate a CL_CONTROL request primitive that enables/disables wireless cycle master, as 
defined in clause 6.5. 

C.4. 2 Isochronous stream connection control 

The upper layer shall use the mechanism for isochronous data flow management, as defined in clause 6.9, i.e. the 
connection management procedures, described in lEC 61883 [5], clause 8 of part 1, with the following adaptations: 

• IRM register access is as described in clause 6.9 (based on command based lock messages). 

• PCR lock transactions response can sometimes report error codes as specified in clause A.2.3. 

• Listener and talker nodes can autonomously disconnect themselves from an isochronous stream, update their 
PCRs, signal the 1394 controllers by writing to the INTERRUPT_TARGET register (see clauses 6.9.2.2, 6.9.2.3 
and A. 1.3). 
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